Problem running two parallel while loops

[billko]

You're pretty close, but let's start with something a little more basic...

[avi0111]

Hi Billko,

    I tried the modified version and still no string in the Trimmed string readout. No other errors but no it's almost like there is no data going through the cables.

Thanks,

avi0111

[billko]

---

@avi0111 wrote:

Hi Billko,

    I tried the modified version and still no string in the Trimmed string readout. No other errors but no it's almost like there is no data going through the cables.

Thanks,

avi0111

---

Hi, avi:

Just to be certain, you were manually pressing the print button on the equipment itself?

A small mod to the vi needs to be made to make the error handling better.  Replace the tunnels for the error cluster on the while loop with shift registers so we can see any errors propagate.  Or (provided you have automatic error handling on), you can simply delete the wire coming from the VISA read to catch the error immediately.

[billko]

Reading the manual again, I see that you have handshaking to "none."  I would try "xon/xoff" first, then the others.  It is clear that it needs some sort of handshaking.

[avi0111]

Hi Bill,

    As per your advice, I replaced the tunnels with shift registers and I am attaching a screenshot of what I got on the error indicators. The result was the same as shown in the screenshot for Xon/Xoff, RTS and DTR modes. Please advice on the error.

Regards,

avi0111

[RavensFan]

There is one problem with having shift registers on loops for error wires.  If you ever have an error, that error gets passed to the next iteration.  Most LabVIEW functions will not do anything if they have an incoming error and just pass the error through.  So if you have one stray error such as a time out error, then that error persists forever never allowing the code to do anything until you happen to stop and restart the VI.

You'd be better off having normal tunnels, and using the error indicator to spot errors.

[avi0111]

RavensFan, you are right about the error propagating through iterations. Error counter 1 shows an error only from the second iteration. Can you give me details on what type of error it is, and how do I correct it?

Thanks,

avi0111

[billko]

It's a timeout error.  I'm guessing that something is wrong with the communications settings.  I you have communications software like Hyperterminal, you might try configuring settings in there and see if you can communicate with it there.  One question: your equipment is really on COM3?

RavensFan:

If you didn't wire it with a shift register, then how do you know if an error occurs if it gets swallowed up by a "no error" condition on the next iteration?  If you wanted to get technical, you could wire your loop to also exit on error.

[RavensFan]

Put the error indicator at the end of the loop rather than at the beginning of the loop.

That error is the timeout error.  It means you didn't get the 200 bytes or a termination character within the 10 seconds of timeout you had specified.  So you still have a problem with the communication.

I may be repeating earlier messages with this (I'm not going to read back to see if this has been asked before), but have you ever proven the communication works through other means such as using Hyperterminal, or some software that the device manufacturer may have provided?

[billko]

RavensFan:

Hmmm, after thinking it through, I guess it doesn't really matter about shift registers or not if you have proper error handling included in the loop, except without shift registers, you don't have to worry about clearing errors with your error handling - which seems pretty convenient, come to think of it.  For t-shooting purposes like though, you're right - it's best NOT to have the shift register so you can look at the results from each iteration and know the error is from that one and not a "stale" error and also that the everything is really being executed.

I should thank you for making me think things through.

[edit] - thanked with a kudo