Trying to update channels in real time while controlling Agilent 34970a

[Akello]

Hello all,

I've gotten such valuable help on these forums and I am hoping that someone will be able to point me in the right direction with this issue. I'm still pretty new to LabVIEW so please bear with me.

I am working with the LabVIEW driver for the Agilent 34970A connected over a GPIB-ENET 100/1000. The device was detected and works just fine. The reason I am writing today is that I am trying to update the channel list in real time. Currently I need to stop the whole process in order to edit the channel list but due to the nature of the tests we will be performing it is important that I can add more channels as I go without interrupting the testing going on.

I've searched the forums and tried modifying the channel string control to "Update value while typing," and "Limit to single line." The motivation behind the latter change was so that I could modify the channel list and use the ENTER key to execute. I've also tried creating a while loop with shift registers but the construction ws so clumsy that it did not work either.

I am pretty sure that the modification should occur right at the string control but cannot be certain since the pint is for it to reinitialize what channels to scan and that occurs further down in the VI. I've attached the VI I am working with; it is an only slightly modified version of the driver's Advanced Scan Example. 

Thank you all in advance,

Yusif

[smercurio_fc]

The fundamental issue is that the string controls are read at the beginning, and once you go inside the loop, any changes in the string control are irrelevant. You need to look for changes inside the loop. A simple solution is to use shift registers/feedback nodes to keep track of the last value of the controls (initialize them to an empty string), and update the channel list if the control changes. However, if this code is going to grow (as it likely will) you should consider looking at a different architecture. A state machine would be a good start. Application Design Patterns: State Machines

Also, do not use string functions to create paths - use the file functions. And don't hard-code paths in the code. That's mucho bad.

[Akello]

Thank you, your advice did the trick!

I am still learng to crawl so I used the shift registers as opposed to building a State Machine but I will be looking at them in the near future. It's a little strange that my LabVIEW learning book has no mention of them but I think there is sufficient information online.

The only problem I am having now is the time it takes to update. I was thinking of adding a Wait (ms) inside the while loop but I think that might interfere with how often the MUX takes measurements. I as thinking of maybe breaking up the while loop but I get the feeling it will cause more problems than it fixes. Any advice on how I could control the channel update (shift register) timing independant of the reading timing?

Thanks again,

Yusif

[smercurio_fc · Accepted solution]

You may have added a shift register, but you're not actually comparing anything. You need to compare the value of the control to the value of the data coming from the shift register to see if it changed. If so, change the scan list.

If you need to have a delay after changing the scan list, then you should add the delay inside the case structure that calls the VI to reconfigure the scan list. You can use the Time Delay VI to cause the delay to occur after configuring the scan by using the error wires to force execution order.

P.S. Your naming scheme for VIs implies that you are probably not using a source code control system. If so, you would be well served in taking the time to learn about source code controls systems and installing one. It's very easy, and there have been numerous threads in the LabVIEW forum on recommendations of source code control systems.

[Akello]

I updated the VI based on your suggestions as I understood them. The change seems to have done the trick and the timing ofthe channel update is different from the timing of the readings. Am I overlooking anything?

Now I have a silly problem; the stop of one loop is linked by timing to the stop of the other. When I press the stop button, it waits the channel udate wait-time until completely stopping the whole VI. The mechanical action on the Boolean is limited because I have a local variable so one control stops both loops. I could live with this but I'm curious if there is a way I don't have to. 

The advice is very much appreciated, thank you.

Yusif Nurizade

[smercurio_fc]

Actually, you didn't understand my suggestion at all. Where did I say to create a second loop and then create a local variable in your main loop? What I showed you was a miniaturized version of your loop. The case structure inside the image I posted was the first case structure you have (minus the additional check to see if the string was empty).

You would obviously need  a second shift register for the other channel list.

[Akello]

I saw the case structure inside a while loop and thought that applied only to the part that controls the channels. Initially the second loop was not there but the VI didn't work without it.

I'll try to adjust the VI based on your clarified suggestion. In the meantime, what is wrong with the way I set it up? It works and does what I want it to do minus the minor kink with the STOP button. Is this a bad design issue or something I am not seeing?

Thanks,

Yusif Nurizade

[smercurio_fc]

---

@Akello wrote:

I saw the case structure inside a while loop and thought that applied only to the part that controls the channels. Initially the second loop was not there but the VI didn't work without it.

---

Then you must have coded it incorrectly since all you needed to do was to have that first case structure execute if the channel list was not empty AND the value had changed. Determining if the value was changed would be a simple matter of comparing the control's value agains the shift register value..

---

I'll try to adjust the VI based on your clarified suggestion. In the meantime, what is wrong with the way I set it up?

---

You mean other than the fact that you had a loop you didn't need, a local variable that you didn't need, a loop that would only respond once every 10 seconds (meaning that if you clicked the Stop button you might have to wait up to 10 seconds before it actually stopped), and that you weren't actually controlling the reconfiguration of the channel list based on whether there was actually a change in the control value?

Absolutely nothing.

[Akello]

I appreciate the advice you are offering. It's invaluable especially since even when I misunderstan it, the VI does what I want it to.

That being said I don't understand why you are being condecending in your responses. I'm still a beginner at this language and I make mistakes. I tried my best to follow all your suggestions and got the VI to work, albeit with some design flaws.

If you can't be civil I can ask others for help. If you do want to help, I've edited the VI according to your latest clarification and the placement of the Wait(ms) is giving me trouble. When I put it where you suggested, it affected the reading time. Placing it inside the Case Structure seemed to do the job. How does it look now?

Yusif

[smercurio_fc]

I fail to see where you thought I was being condescending. Sarcastic, yes, as that was exactly what my intent was. Condescening, hardly.

I think I'll let someone with a bit more of a silver tongue aid you.