VI stuck in a continous loop

[BadAzzS10]

Hi guys,

I am at my wits end on this and need your assistance.

I have a Chatillon force gauge that I can communicate sucessfully with. I've verified that my Baud Settings, Data Bits, Stop Bits, Partiy, and Flow Control are correct. I have also verified that I can communicate with Hyperterminal.

I am trying to change the type of mode the gauge is set to, but my Bytes at the Serial Port node always states zero, so my EXE is always in a continous loop. When I go into the VI and manaully change the settings, I can communicate sucessfully with it.

I've attached the VI and the manual.

[JÞB]

It looks like you simply need to append a CR-LF to each of your writes.  (or and EOL constant in Windows)

The device won't accept that the data is valid until it sees the EOL show up on the serial line.  Hyperterminal defaults to sending EOL with writes LabVIEW VISA ser:inst defaults to just sending a 0x0A (LF).  You can change this by writing the Send End on Writes property of the VISA resource.

[RavensFan]

To be clear, hyperterminal doesn't default to sending an EOL on writes.  It sends whatever you type into it.  So if you just hit P, that is what is sent, if you hit the enter key, then a carriage return will be sent.  Now there is a couple settings under "ASCII setup" that will do some conversion between carriage returns and CRLF's.

Now you may need to send a carriage return or a linefeed after sending the letter command, in which case it is easiest to put it right into the string constant.  But it isn't clear from the manual whether you need to do this.  From what I read around page 30, it looks like just sending the letter is enough.

I think a bigger problem with your VI is that you have no wait between sending the letter command and doing a check on the number of bytes at the port.  You probably haven't given it enough time to return anything so the bytes at port will be zero which means you don't read anything.  Later you send the F command then immediately clear the buffer.  (Why are you clearing the buffer there?)

Between not waiting for a response and a convoluted way of sending different commands through the shift register.  I think  your VI is stepping all over itself sending the wrong commands at the wrong time and never seeing any responses before it wipes the buffer clear.

[BadAzzS10]

How do I apply the wait? Is it basically just the Wait VI or is there special VISA function that does this?

[10Degree]

Use the VISA Configure Serial Port vi to set up your serial.  Set "Enable termination char" to FALSE and then append your termination characters to each string you send to your device.  If your device uses only a single termination character, you can enable the termination character and then specify the ASCII value for the termination character using the same vi.  Check the help on that vi if this doesn't make sense.

[RavensFan · Accepted solution]

---

@BadAzzS10 wrote:

How do I apply the wait? Is it basically just the Wait VI or is there special VISA function that does this?

---

You just use the Wait VI.  But you need to put it in a flat sequence frame so that you guarantee the wait occurs before you try to look at the bytes at port.

[lmtis]

---

@Ravens Fan wrote:

You just use the Wait VI.  But you need to put it in a flat sequence frame so that you guarantee the wait occurs before you try to look at the bytes at port.

---

I can't believe that NI hasn't corrected that yet.  I carried my own wait with error VI from job to job until I discovered OpenG

[JÞB]

I once posted a robust "Wait" vi that has some of the improvements suggested by the other responders.  You can find the link here.  Make no mistake- I like the OpenG palettes.  But, in my possition, I need to "roll-my-own" reuse library. And, my example has some advantages over the OpenG vi.  (like not hanging when the mS timer rolls) <bad joke ahead> Besides, I'm something of an amature horologist (don't tell my wife) 

[TCPlomp]

---

@Jeff Bohrer wrote:

. And, my example has some advantages over the OpenG vi.  (like not hanging when the mS timer rolls)

---

How does the OpenG version hang when the ms-timer rolls?inside the code there is no check done on the actual value so I don't see how that could happen (unless it would happen with the LabVIEW primitive as well).

Ton

[JÞB]

---

@TCPlomp wrote:

---

@Jeff Bohrer wrote:

. And, my example has some advantages over the OpenG vi.  (like not hanging when the mS timer rolls)

---

How does the OpenG version hang when the ms-timer rolls?inside the code there is no check done on the actual value so I don't see how that could happen (unless it would happen with the LabVIEW primitive as well).

Ton

---

I hit lightning in a bottle many years ago and found a vi Stuck in "Wait +(mS).vi" the standard DAQ counter wait with error.   The test case is to begin the wait with the condition that the OS mSec timer will rollover while waiting.  a U32 +inf incremented resulted in a exit condition that could not be met.  since a -U32 is ALWAYS less than an I32.  One of the reasons that the Wait til mS multiple primitive also exists on the palatte and sometimes preferred for loop timinng.  The last I reviewed the OpenG Wait with error it was funtionally identical to Wait +(mS).vi

As to the LabVIEW primitive- I cannot elaborate, can't see the code.