VI works properly every other time

[mikeporter]

---

@crossrulz wrote:

---

mikeporter wrote:

PS: Just had a thought, does the fact that I can remember when HP made rack and stack instrumentation make me old?  

---

You mean before they were bought out by Agilent and then spun off into Keysight Technologies?  Oh, the spin off isn't completely official yet.  Well, give it a few months.  But, yes, that does make you old.

---

***Sigh*** That's what I was afraid of...

Mike...

[EMorrison]

Hey I'm not that old and I have had HP rack-mount hardware. I later purchased replacement Agilent versions. I have been getting away from them though in favor of other vendors.

There is an older version of this software that uses hard coded values and an older non-visa driver that works almost every time it runs. That version might have a 10% failure rate. I'll give RTSLVU's version a try, but is there a way to take the old version from the production machine and put it on my development machine? This would give me more evidence in whether it is my VI or the driver.

Thanks,

Eric

[EMorrison]

An update. It turns out that the VI which controlled the output relay on the load was the problem. This was in the driver package and even I could see that it was overly complicated. What would happen is they would store the state of the output relay in a boolean on the front panel and rely exclusively on this boolean to be correct before sending commands to the load. So if this boolean got out of sync with the actual relay nothing would happen. The driver did no error checking to confirm with the load that it was in fact in sync. There is no harm in sending the command to the load repeatedly (unless that communication is getting in the way of more important communication) so I cleaned out all the code that had the driver decide if it should write out or not. Now it simply does what I ask when I ask. Since the trouble was with the driver I have not posted updated code. I have created a state machine version fo this code that seems to be working too. Thank you all for the help.

Regards,

Eric

[billko]

---

@mikeporter wrote:

<snip>

PS: Just had a thought, does the fact that I can remember when HP made rack and stack instrumentation make me old?  

---

I hope not.  I can remember when trace memory was a grease pen and taking a screenshot of a scope trace involved a hood and a Poloroid camera!

[billko]

---

@crossrulz wrote:

---

mikeporter wrote:

PS: Just had a thought, does the fact that I can remember when HP made rack and stack instrumentation make me old?  

---

You mean before they were bought out by Agilent and then spun off into Keysight Technologies?  Oh, the spin off isn't completely official yet.  Well, give it a few months.  But, yes, that does make you old.

---

I think HP split in two.  Then Agilent bought Varian, which was pretty much the grandfather of all things RF.

[billko]

Oh yeah, I can also remember a time when a frequency generator had an analog pointer and you had to use a frequency counter to dial in the correct frequency.

[mikeporter]

---

@EMorrison wrote:

An update. It turns out that the VI which controlled the output relay on the load was the problem. This was in the driver package and even I could see that it was overly complicated. What would happen is they would store the state of the output relay in a boolean on the front panel and rely exclusively on this boolean to be correct before sending commands to the load. So if this boolean got out of sync with the actual relay nothing would happen. The driver did no error checking to confirm with the load that it was in fact in sync. There is no harm in sending the command to the load repeatedly (unless that communication is getting in the way of more important communication) so I cleaned out all the code that had the driver decide if it should write out or not. Now it simply does what I ask when I ask. Since the trouble was with the driver I have not posted updated code. I have created a state machine version fo this code that seems to be working too. Thank you all for the help.

Regards,

Eric

---

Actually, believe it or not that what you are seeing might be an implementation of an approach to driver design that HP was pushing called "Instrument State" programming. The idea was to save on bus transfers by having the application software remember what state the instrument was in so it only had to send the values that changed. It worked fine -- except for that whole synchronization thing... On most instruments, the front panels don't automatically lock when they are being controlled by GPIB (and still don't - hint, hint) so an operator could walk up at anytime and change the instrument settings to something the driver wasn't expecting.

Mike...