Visa serial don't work sometimes.

[RavensFan]

When it doesn't work, what is happening?  Do you get an error code?

It is very odd for your code to freeze up that the Get Data button stops working.  With the timeout on the VISA Read, it should come back within 10 seconds (default timeout setting) assuming nothing is being returned by the scale.  You could make that timeout value lower, perhaps down to 1 or 2 seconds by wiring a constant into the Serial Configure.  Is it possible that the button does get read, but you just aren't waiting long enough to see it happen?

A couple things I see unusual in your code.

1.  Generally the Write comes before the Read.  You write a command, read a response.  Having the read first means you might

2.  For the command to get data, you have "E"=H45  but something I think is missing is a termination character on that.  Generally instruments that send termination characters on their responses also require them on the commands sent to them.  So set that constant display to \codes mode, make the display style visible so your code is visually documented that the constant is in \code mode, and add \n add the end of the constant which is the slash code for "new line" or the linefeed character.

3.  You have only a constant out in the Get Data case structure.  So if the button is false, you write nothing, what do you expect to get as a response?  If nothing which would be typical in a Command/Response protocol, the VISA Writes and Reads also belong in the case structure.

You might want to put a Bytes at Port node in there going to just an indicator.  I know I say that 99% of the time Bytes at Port is wrong, but in this case I would use it strictly as a debugging tool to make sure you are getting bytes in the port.  If the value is continually growing, that is a sign that perhaps the device is sending multi-line responses.

Reading your response more, it sounds like you are trying to achieve 2 modes of operation?

1.  Program sends a command, receives a response.

2.  You manually hit a physical print button, and the device sends a response despite the fact the program hasn't sent anything?

Is that correct?  If so, there is a way to modify the program to more smoothly handle both situations.

[crossrulz]

Well, your command is just completely wrong.  All you need to send is E, which is 0x45 in ASCII.  And, as already stated, you need to request the data before you can read it.

Give this setup a try.  We can wait until later to parse the data once we consistently have it.

(VI saved in 2013, snippet is in 2018)

[Frozen]

Having recently written code that accept continuous stream of data from a scale (or balance), I can tell you that you will want to add a flush buffer after opening the COM port. The process I recommend is as follows:

1) Open COM port

2) wait up to 75 ms for Windows to assign resource

3) Flush buffers

4) start reading from the COM port

However, it seems that you can control the scale in regard to when it sends data.

Also, you do not need to append a termination character to the command since the VISA Open vi has been left mostly with default settings. IE Enable Termination Char default is TRUE, so VISA automatically adds a termination character to any command sent (It does for LV 2016 )

As RavensFan pointed out, you will want to send the command before reading from the scale.

Also, since you are using termination characters by default, set the bytes to a larger value, like 99 (instead of 20)

As you have it coded now, it will continuously try to read ( while loop) regardless if you push the "tara" button. Is that the behavior you intend?

[RavensFan]

---

@Frozen wrote:
Termination Char default is TRUE, so VISA automatically adds a termination character to any command sent (It does for LV 2016 )

---

That is not true.  The VISA Configure termination character only affects READS of the com port.  It doesn't automatically append a termination character to commands you write to it.

You should explicitly add the termination character to the end of the command you are writing.

You can use a property node to set VISA to send the termination character at the end of each VISA write, but it does False by default and thus doesn't do it automatically.

I do not to use this method and prefer to put the termination character in the command to be written explicitly.

 

[Frozen]

Actually, I you are correct. By default VISA does not append the termination char on send. I had modified my open to explicitly do so.

Sorry for the confusion.

[ManuSpadim]

Hello.

I seted the indicator for \code and I saw the \n character so now I’m using it, despite it seems not to change anything immediately.

For the last question, I’m not intented to use the program in two modes. I just want to use it by controlling with the computer. I’m sending “E” which is the same that pressing “print” in the scale, but I just observed that pressing the print button it was working. Now I know there is two reasons for this last question I've asked:

1- I was not waiting for the time out for seen the value. I changed it and it started to work, as ravens said, but sometimes not, because of the problem number 2, below.

2- There are 4 configurations for this scale to send data: PC control (write when I send E, which is the same that press print physically), continuously, pressing print button physically on the scale or using a specific printer for this brand. Of course I was using the PC control, and When in the PC control mode, The scale don't send the data while the weight is not stable.

I wish I could figure something out for collecting the data even in unstable conditions, as I'm willing to measure the mass loss of a component while it burns (of course there is a temperature protection device for the scale), but I think I can’t.

So I made it to send data continuously to the computer and I’m flushing it everytime I read. Do you see any problem in that?

[crossrulz]

---

@ManuSpadim wrote:

So I made it to send data continuously to the computer and I’m flushing it everytime I read. Do you see any problem in that?

---

You will get out of sync with your messages.  What I recommend is to have a loop do nothing but read the data from the serial port and send the data to other loops via queues, User Events, Notifiers, or just store them in Global Variables.  You can use a Queue or Notifier to send a message to this loop to tell it to stop.