Problems using event structure to write new parameter values to VISA

[BassBijj]

Hi all,

I created a VI to read an Omega flowmeter. It is possible to change the gaz (O2, CH4,..) and the set point (consigne (0-2) SLPM) of the meter. To read from instrument I have to write its ID (A to Z) followed by a carriage return e.g.: A+0x0D

I created a VI with events to only write parameters to the instrument when a value is changed. My VI is working but from time to time it does not write the parameter change (gaz or set point). I think is has something to do with the while loop containing a VISA write.

FMA Open contains VISA opend and parameters

Timeout case initialize by writing the gaz and set point for the first time

Other events are for value change of gaz and set point

How can I ensure that all parameter change will be writtent to the instrument ?

Thanks,

[GerdW]

Hi Bass,

don't (ab)use the event structure in this way…

- You constantly fire events using "Val(Sgl)" property nodes of "Count": this code belongs into the timeout event! No need to fire new events instantly…

- The part currently in the timeout event case should be executed before your loop!

- Then you need events handling value changes of "gaz" and "Consigne"…

All your string constants should have the display mode visible. And you could use FormatIntoString to simplify your VI a lot…

[BassBijj]

Oh my..

I think I had some saving problems..the VI I attached is not the right one I realized my mistake: firing A LOT of events and corrected it. The new one doesn't use a count..

 - The part currently in the timeout event case should be executed before your loop!

            Okay, it's true I lose the timeout functionnality that way.

- Then you need events handling value changes of "gaz" and "Consigne"…

             New VI does that I think

All your string constants should have the display mode visible

              I'm not sure I'm following you on that one

And you could use FormatIntoString to simplify your VI a lot…

              Thanks for the hint, I'll sure do that !

The new VI handles events sometimes..but sometimes it misses some change..I think it is because there is a write in the while loop. Do you have any idea how to avoid this ?

[JÞB]

mobile device right now so I can't actually see your code. But if you have a branched visa wire going to to parallel loops you have done something significantly wrong. Go ahead and use one loop to communicate to your device do not even try to communicate to a single device with two different parallel loops .  this way is insanity and will cause you headaches.

Look into a producer consumer design pattern.  you do not need any code in the timeout case.  You do not need a timeout case.  You need some value change cases that pass commands and strings to the io loop via a queue.  Like, command ="Update GAZ", data=1234.

Those VISA reads and writes in parallel loops are blocking and cause all sorts of timing problems.  Just like you report happens in your code!  

One io session one loop to find them, one loop to rule them and in the state machine bind them.  To paraphrase Sauron.

[GerdW · Accepted solution]

Hi Bass,

Okay, it's true I lose the timeout functionnality that way.

No, you don't lose that functionality. You place it in a different position.

You need to call it BEFORE your loop!

I'm not sure I'm following you on that one

Why aren't you sure? You have a lot of "0D" constants and it would be perfect to see that they are displayed in HEX mode instead of normal display mode!

The new VI handles events sometimes..but sometimes it misses some change..I think it is because there is a write in the while loop. Do you have any idea how to avoid this ?

Never, NEVER use parallel loops to write and read to the very same device on your serial port!

How do you want to ensure you always get the correct answer to your command sent before?

What's the purpose of using a second loop here? A loop without any wait states?

[crossrulz]

I'm with the others here.  Your initializations should be done before your loop.  Then anything you need done repetively (ie, what you currently have in the second loop) should be in the timeout case (with some reasonable timeout).

Since you are doing a command/response with the instrument, it is EXTREMELY important that you do not interrupt that.  So what happens if somebody changes the value right when your second loop sent the data and before it can respond, you are already sending the data for the user event?  You likely just confused the heck out of your instrument.  So move that second loop into the timeout and initialize before your loop.

Another note, you could be trying to do the command/response in the second loop before the initialization is actually done.  That could also lead to problems.  Yet another reason to move that initialization out to be before the loop.

[BassBijj]

Hi again all,

Thanks for all pointing my big mistake, I think I learned that now (initialisation and parall. loops) 🙂

@GerdW, I meant that by using the timeout to initialize I wasn't able to use it to read repetively that's why I needed a second loop. I moved initialization out the loop and used the timeout as said, it works no

Also what I meant by I don't follow is that I didn't understand because I didn't know I could make appear the display mode, I found how and it is a very good idea. I also used format into string and it really simplified my VI.

@Jeff·Þ·Bohrer, I really liked your paraphrase. I'll look into turning this into a producer/consumer design but is it really needed ? In what is it better ?

I attached new VI, for loop after event structure is to remove any empty element of string array. If you have any other comments I'm more than happy to get them 🙂

Thanks all,

[JÞB]

Those design patterns are there because of all of the other programmer's before us.  

Saying " should I really bother? " is silly.  

Now go and sling some wires!

[kleingasturbine]

Hi there,

 I´m currently working with FMA-2600 Massflow controller from OMEGA and want to write a LabView Software for writing set points and reading values from the device. As you seem to allready have some software available, would you be willing to share? Actually your FMA_event is pretty complete. But what does your "FMA Open Visa" exactly do?

Best regards,

Jan

[BassBijj]

Hi Jan,

FMA OPEN contains the visa open configured for this instrument, nothing fency here (see screenshot).

This VI needs a little fixing, after working a little more with FMA devices I realized that whenever you input them the command to change the gas or the set point it output its reading like I would when inputing the normal read command (instrument ID <enter>). It means you have to add a read operation after the visa write in the event structure for the gas and consigne value change event.

If you want to do better, I would recommend like it was suggested to me in this thread to turn this into a state machine using queues, or event further with a consumer/producer design. It depends on what you want to do..if you just want to control the FMA with a VI and log the data a simple state machine should do I think (with a case handling value changes). But if you are trying to have another VI controling the FMA VI, queues may come out handy. 

Regards,

Bass