table

[billko]

---

@ogk.nz wrote:

---

crossrulz wrote

So the logical thing to an engineer is to increase the wait to something like 100ms.  Ok, this time you got all the data.  But you wasted 25ms waiting for the data.  25ms does not sound like much, but in some of my test systems, that has added up to over an hour of test time.  And, for some reason, let's say the instrument has a hiccup and takes 150ms to send all of the data.  Oops.  You didn't get all of your message again!  Increase the wait again?  Sure, let's just make it 1 second to make sure we always get the message.  That will really increase your test time!

Back to just using the termination character, the only possible timing issue you have is the Timeout, which defaults to 10 seconds, which you should only ever take that long when something is terribly wrong.  As soon as the message is recieved, you are off and running.  No wasted time with arbitrary waits and no missing data to your messsage.  It is by far the best way to do serial communications (assuming the instrument's protocol does it).

---

This is kind of making me rethink my stance, but I know coming from working with serial port rather then visa (WinCE devices YAY!) I have used a rather similar method to bytes at port, where the system will read the number of bytes at port every 25ms up until the timeout value. If the byte value remains 0 it continues to timeout, if there has been a some length of data received then it waits another 25ms and if there has been no change in that 25ms period then the subVI is stopped and the message is passed out. In this version the maximum duration to overextend the read process is by 50mS.

---

Sure - and that is how the LabVIEW examples have it, too.  (Don't get me ranting about how the serial examples need to be updated!!!)  But communications using VISA can be much more efficient than the brute force method you are using.  🙂

[Dennis_Knutson]

Other api's do not have the VISA feature of automatically terminating a read when the termination character is detected. That is why they might use the bytes at port function in a loop. This is not something that should be ported to LabVIEW.

I've never noticed any difference between specifying 100 bytes or 100000 bytes as long as a termination character is present.

[drek123]

what im trying is with te switch boolean to write a value to the table wich should stay there and not change until end of measurement

[William1225]

Hi crossrulz,

Thanks to your detailed explanation, but your definition of race condition is a little different from mine.

I thought it happened when two or more accessing to the same variable.

Anyway, I'm a coward so that I wonder if there is a safer way to make me "feel better"(though nonsense)...

Could I do in such a way to collect the data exhaustively?

Thanks again to your help!!

[billko]

---

@William1225 wrote:

Hi crossrulz,

Thanks to your detailed explanation, but your definition of race condition is a little different from mine.

I thought it happened when two or more accessing to the same variable.

Anyway, I'm a coward so that I wonder if there is a safer way to make me "feel better"(though nonsense)...

Could I do in such a way to collect the data exhaustively?

Thanks again to your help!!

---

That's a lot of unnecessary code, assuming SCPI commands over a serial port.  Just forget the loop stuff.  The code is unecessarily paranoid.

[edit] I guess technically that's IEEE-488.2, but what would follow are probably SCPI commands. [/edit]

[ogk.nz]

This may be slightly off-topic but just to clear it up, If I have multiple devices on the same COMPort (RS-485 Counter and a RS-485 AI say) and they have different termination characters is there a way to have multiple termination characters on a single VISA connection? I assume this is simply asking for trouble given the chance of splitting messages but it might help solve some things.

[RavensFan]

No, you can't have have multiple termination characters.

If you have multiple devices on one serial port because you are using multi-drop RS-485, the devices should be speaking the same protocol, and should not be trying to talk at the same time.

[drek123]

does any knows whats wrong with this formula node  ?

thx very much

[GerdW]

All the wires are broken! 😄

Did you read the help for the formula node? All the syntax elements are explained in there!

Which error message do you get when you try to run your VI? LabVIEW points out the error(s) it finds…

[drek123]

formula node undifined variable

error on line 2 is marked by a '#' character :" if # val = 1;"