LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Julabo RS232, FPGA, RT, FIFO

Solved!
Go to solution

Hey there,

 

trying to establish a connection to a Julabo F33 ME Refrigerated Circulator. Im using cRIO9074, and the module: NI 9870.

I got a template (FPGA.vi, RT.vi) from a colleague who is running his julabo circulator on a similar system. Somehow i cant manage to send any commands to the device neither getting information back.

 

RT.vi: I modified the vi to send a command (String: in_sp_00) to the julabo (Mod1/Port1). I am sending only empty strings to the other ports since i just want to test the first one. It should answer with the recent temperature, but i cant get any answer.

I double checked the connections and the settings of the com-port...

 

Find the VIs in the attachment.

 

I hope someone can find the error(s).

 

Regards.

Download All
0 Kudos
Message 1 of 14
(3,552 Views)
Solution
Accepted by topic author ikkebins101

Can you also include the "Write sub-VI"?

 

One common error with serial communication is forgetting to include the new-line or termination character after sending a string. Does the chiller expect that every command will end with a carriage return, line feed, or both? If so, you need to include that in the string that you send. Right-click on the command string constant, choose "'\' codes display", and add "\r" for a carriage return or "\n" for a line feed at the end (or, just hit enter at the end of the string constant to add a new line, that often works too).

Message 2 of 14
(3,532 Views)

YESSSS! You are right i forgot the termination charcater. So simple 🙂 .

 

Thank you very much, the problem is solved!

0 Kudos
Message 3 of 14
(3,525 Views)

Hello everyone,

 

i have another major problem. When i am sending commands to more than one port the device reacts very lately or not at all.

 

Picture 1 shows the commands im sending through Port 1 (RT.vi). If i send commands through port 2 i start to get problems. After disabling every other commands on the other ports everything works properly again.

 

Somehow the channels interfer. I integrated "waits" in the block diagram, but it didnt help.

 

I have attached the VI´s and the picture.

 

Any suggestions how to solve the problem?

 

Regards.

Download All
0 Kudos
Message 4 of 14
(3,495 Views)

8 ports -> 800 ms wait and it worked.

 

--SOLVED--

0 Kudos
Message 5 of 14
(3,488 Views)

Hey there,

 

I have the same problem again. Trying to send commands to 2 or more ports the problems begin. It is the same problem as i described above:

"When i am sending commands to more than one port the device reacts very lately or not at all."

And sometimes commands which are supposed to be send to e.g. port 1 is send to port 5. So everything is mixed up.


Does anyone have an idea what the problem is?

 

The command structure is correct.

 

I think it is somehow related to the FIFO. Maybe the assignment is not correct so the commans are not transmitted to the right port.

 

I have attached my recent FPGA and RT.vi.

 

 

Please help, i am desperate. Struggling with the problem since 3 days!

 

Regards,

ikkebins101

Download All
0 Kudos
Message 6 of 14
(3,454 Views)

I suspect that part of the problem is that if you send commands to two different chillers in rapid succession, you might update the "Port to Write (FPGA)" or "Bytes to Send" control for the second command before you read all the bytes out of the FIFO for the first command. That would result in sending a command to the wrong chiller, or sending too many or too few bytes. Or, you might set "Write Data" for the second command and have it cleared after sending the first command, in which case the second command would not get sent until you try to send a third command, which could look like it's reacting slowly.

 

Unfortunately I recommend spending more time reading through FPGA-specific programming recommendations, and reworking your code. There's no need for the error wires on FPGA; they consume excess resources and rarely provide value. You might also want to consider an architecture in which you don't have the possibility of writing to FIFO READ in multiple places simultaneously, to avoid arbitration (do you have arbitration enabled on the FIFO)?

 

Also add a handshake between the host and FPGA that acknowledges that a command was transmitted before attempting to transmit the next command.

Message 7 of 14
(3,426 Views)

Hello,

 

thank you for your extensive answer.

 

After your answer i tried several things to overcome the described problems. To check the hardware i wrote a simple FPGA.vi to transmit and receive date from crio modulni9870 to another computer running HyperTerminal.

But finally i found out that my FPGA.vi somehow stops running:

At the beginning everything works correctly. I can transmit and receive data. It even works if i send commands simutaneously by multiple ports. But a few seconds after i hit the button "Update Config" (updates serial configuration, baud rate etc.) there is no longer data transmitted or received. I get no error messages and still can hit the button, but apparently the vi is not really running, because the "Update Config" button is supposed to changed to "off" again after hitting it. This doesnt´t happen anymore a few seconds after i hitted it the first time.

 

//edit

To make it run again i have to reboot the rio

//

 

Is this a sign that there is an hardware problem? Because the part of the FPGA.vi, which causes the problem (Update Config) is running on a similar system of a colleague without any problems.


Thank you for your help and kind regards,

ikkebins

0 Kudos
Message 8 of 14
(3,353 Views)

I forgot to attach the FPGA.vi.

 

Here it is 🙂

0 Kudos
Message 9 of 14
(3,348 Views)

Are you sure you're not unexpectedly resetting or aborting the FPGA VI from the host? I don't immediately see anything wrong with the FPGA VI, but it would surprise me if you have a hardware error.  Try eliminating serial ports one by one perhaps, and see if there is one specific port that causes the issue (in which case yes, it probably is a hardware problem)?

0 Kudos
Message 10 of 14
(3,308 Views)