Problem with timing a driver

[inuyasha84]

Hi there!
Using the State Machine system, I want to realize a driver for the LeCroy waveRunner 64Xi.
Attached there are the first step I did.
Well (please close an eye on the use of local variable that I'll remove later I'll swear) the problem is that if I run the VI with the "HighLigth execution mode" it seems that everything works properly, instead in normal mode I'm not able to see these 2 messages: "Chiamata Strumento In Corso...." (and this I could explain saying ok maybe the for cicle run too fast) and the exit on the read buffer during the Reset and Testing phase (for this I have no explenation).
Can you help me?
Thank you

[inuyasha84]

I found one solution like the one shown in the attached file... but I'm not sure if it is correct.
The idea is do a control on the error bus and wait for the "Chiamata Strumento In Corso...." (in this way it is shown) and, since it seems that the response to

*RST;
*TST?;

requires more time in this case I thought to put the waiting in a case structure (but I dunno if this is a correct way to do these things for a driver).
If it is correct ofc I'll do the same thing also for the identification.

Hope you can help.

[crossrulz]

Instruments need time to respond.  So adding delays between the write and read is very common.  I've also ran into insturments where I need to wait so long before sending a command while it processes the previous.  But there is bus lag and communication time.

[inuyasha84]

do you think that the way I have found in the last VI is correct?

[crossrulz]

3 seconds seems excessive to me.  You also shouldn't have case structures with just 1 case (I'm hoping you aren't doing that for real).  And your waits are after the reading of the reply.  I typically just see the waits between the request of data and reading the data.

[inuyasha84]

ok the 3 seconds are used for 2 reasons: the first is because i wanted to see the string/status; the second is because i really don't know if 3 seconds were too much or too few 😛
about the waits between the request and the reading seems correct. i thought it as well but i was not sure (tomorrow i'll fix it). what i have not understood is the fact that I have used case structures with just 1 case... is it a problem? my idea was to realize 1 subVI for each state this is the reason for the case structure.

[inuyasha84]

Here it is. No more case structures alone, added the SubVIs,  build the timing between the write/read pattern (actually I prefer to have the timing at 2sec but I saw that at 0,5 sec it works properly).

Let me know what do you think about this one 🙂

Ty for your hints.

[Norbert_B · Accepted solution]

OK, first of all: It works as expected?

I assume so, so let's focus on "cosmetic" stuff....and there are some which might bite you in the future when working on bigger projects.

1. It is not common to include "(SubVI)" as part of VI names. As there should only be a single top-level VI (rule of thumb) in an application, EVERY other VI is automatically SubVI. Marking that additionally seems to be overhead.

2. Try to improve wiring. You have several wiring issues.

3. Again: Do not use variables.

4. Writing per value property node is not necessary in your subVIs. As your subVIs return after some time, you can display the resulting state easily after it finished.

5. Waiting times with more than some 100ms are questionable if done in "one chunk". The problem is that the user HAS to wait that time and cannot exit inbetween.

6. Speaking of exit: Stopping the Versione Finale.VI using the stop button leaves the the interface open. There won't be a functional issue as LV automatically handles leaking VISA sessions if not disabled in options.

7. You should define the state enum as type definition. It will make future changes to it manageable.

8. Are you really sure that the IP of the device is constant? If not, you have to change the code each time. Better place it as frontpanel control with a configured default value.

9. It is common for buttons to hide the label on the frontpanel.

10. Do not hide state transition code in a functional subVI. Either you have a specific "Transition" VI or place the code directly in the state machine.

11. Do not place waiting times anywhere over the place. Place them central (state machine) and only in other places where really required.

12. Use the cluster by name functions rather than simple bundle/unbundle.

13. References and VISA handles should always be passed in the top connectors of subVIs, as the error cluster always on bottom (which you already did).

14. Do not use a "no error" to add additional string based information. Either there is an error and the string contains the source inforamtion or there is no error, so there is no source for this.

See attached zip. I did not "update" the subVIs except the connector panes and they are missing in the zip. But i think you can imagine what i changed....

Norbert

[inuyasha84]

0- yes, it works properly
1- I haven't understood what you want to say here...
2- ok
3- ok my fault 😛
4- the property node has been setted automatically when I created subVI soon after I selected the components.
5- i know. it will be reduced
6- my GREAT error! only now I saw it. thank you
7- mmm i need to read something about the type definition. I don't know for what it is used for
8- yes is costant, that's the reason why i haven't put a control as you suggest..because it was boring to set it everytime 😛
9- yea i know, i've been lazy 😞
10- I haven't understood what do you mean here...
11- Sounds as a SUPERB idea. I really haven't thought it. Ty for the hint! this is the most precious
12- ok i'll do it
13- to clean the VI I have used the clean up diagram... ok ok i've been lazy again 😛
14- ok ty for the hint.

15- nice the stop button

[moderator1983]

1. Enum used to define the states of a 'State Machine' should (must) be a type-def, so that if you add a new state, every instance should get updated.
2. You can introduce a state, call it 'Initialize' and that can be used to clear the 'String' and 'read buffer' indicators.
3. Another state, say 'Open Session' (just like you have 'Close') to open the session.