LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

NI VISA Write/Read/Response Issues

Solved!
Go to solution

Hello Friendly Smart Labview Community,

 

I writing a program in labview to write the setpoint value (41003) and read the process value (31001)  from the temperature fuji temperature controller prx4 with ASCII and RS485. 

 

The issue I have is my "response" from the read/write VISA is continually changing. It is repetitive and it does occasionally show the process value and setpoint value that I am looking for. Although, not in any way that is repetitive. Plus, it will send the setpoint value to the temperature controller I am working with. 

Plus, this ASCII calls for two end codes both CR and LF, so that could be causing an issue. 

If someone could please help me out, I would greatly appreciate it. 

I've attached the codes, along with the data sheet of the temperature controller. 

0 Kudos
Message 1 of 9
(3,259 Views)

First, learn about data flow. There is no need for the sequence frame. You could use the error wire to control the sequence of execution. Secondly, I believe your issues may be that you are using the bytes written as the input to the read for how many bytes to read. As configured, your read will stop if it receives a new line character (\n) or the number of bytes specified. The length of the written data is 17 bytes. the length of the response is 21 characters. So, you are not reading the complete response.

 

Set the number of bytes to be read to at least 21. However, you can set it to a larger value such as 32 and let the read terminate at the "\n" character and then read 2 more characters to read the BCC.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 2 of 9
(3,219 Views)

Hi Mark and thanks your reply,

 

I removed the sequence around the write and read frame, but keep it just where I was creating the string command, as that is taking in user inputs. If I should change that too, let me know.

 

I adjusted the bit size to 32, but now I am getting a time out error (see attached).

 

I'm not sure the cause or the solution to that. What do you think?

 

Thanks 

 

0 Kudos
Message 3 of 9
(3,170 Views)

Hi,

 

I've added a time delay, which seems to revolve the timeout error.

 

Although, the original error is still there. My response is changing between

52:001WW41003,004 and 6E:001WS

 

When it should just be :001WSCRLF52, although CR and LF are the end statements which are not appearing anywheres, so perhaps they won't be in the response. So then it would be :001WS52. 

0 Kudos
Message 4 of 9
(3,166 Views)
Solution
Accepted by crossrulz

1. The way you build you message can be GREATLY simplified with the use of Format Into String.

2. You are failing to read the BBC.  Just do another read of 2 bytes.

3. Depending on the RS-485 device, you may need to do another set of reads in order to get the response data (initial read is just what you actually wrote out).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 9
(3,151 Views)

Hey,

 

Your right, that new code is much more simplified. I think we are on the right track here. 

 

The response I am getting is:

:001WW41003,00008
72

From the inputs: station number (1), registers number (41003), data (8)

 

It is repetitive now and able to send the SV value to the temperature controller. That's great!

 

So, for your third point, in order to get the response I was try to create a new "read" for the response. Would you suggest doing it within this VI and using a sequence structure?

 

 

 

 

0 Kudos
Message 6 of 9
(3,140 Views)
Solution
Accepted by topic author jescameron

Hey,

 

I took your previous advice on data flow and did not even need those sequence structure and got a solution. 

 

Here is the working write in and response.

 

Thank you for your help. I'll send some kudos and mark this as complete. 

Message 7 of 9
(3,136 Views)

@jescameron wrote:

I took your previous advice on data flow and did not even need those sequence structure and got a solution. 

Excellent.  Now to make things even easier for the next set of stuff you will need to do here, I recommend breaking up your code into subVIs.  For instance, turn the creating of the Write message into a VI.  Do the same for the Write and Read of the message.  Since you next plan to create a Read message (to read data from a register), you can create a VI for that as well.  This will help you a lot in organizing the larger application.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 9
(3,130 Views)

Hey,

 

Yeah, that is a great idea. I will do that. I will need the subVIs because after I get the one temperature controller able to write and read, then I need to connect two more (stations). So, I imagine having basic, read and write VIs will make that a lot easier. 

Message 9 of 9
(3,125 Views)