While-loop stops unexpectedly

[Zergio]

Hi everyone

I have a problem with while-loops.

Im trying to write a program that allows me to control the temperature of a hot plate, using as a starting point one of the examples in LabVIEW (Basic Serial Write and Read). So basically the program sends a command asking for the actual temp of the hotplate and then it reads a response with the status, then the user writes a temperature (the sub-VI creates the command which is sent to the hotplate) and then it reads a confirmation response. the while loop is to monitor the temp and change it if necessary

Sometimes it works for 30 secs aprox and sometimes for a couple of mins, and then just stops reading, i dont get error messages, it just stops getting a response.

The hotplate is a  pro H550 MS7 and im using a USB to RS232 converter cable

PD, im pretty new using labVIEW, sorry for my bad english.

Greetings and thanks for the help

[Labuser16383]

First you don't need all that sequence structures because your dataflow is given by the error wire.

Then you have those "bytes at port" property nodes and you don't use the values from them.

Probably you mess up your serial buffer by uncomplete reading of bytes and then pushing a new command

when the buffer is still partly filled. This way your response of the recent command gets mixed up with the response of the

previous command.

You should definitly check your delays if they are large enough and flush the port at the end of one run so that you have

determined starting conditions on the next loop run.

[crossrulz]

Do you have a link to a programmer's manual for the hotplate.  I am not able to find it.  What we really need here is to know the exact protocol of the hotplate.  Then we can help you fix your code.

[DanRen_IQA]

Erratic behavior of a program can also point to inconsistent communication with the device. I have struggled with USB to RS232 converters, USB Hubs, and even cheap USB cables causing communication problems, which can lead to seemingly random program failures. Give your communication links a good look. Cheap hardware is rarely worth the cost savings.

Good luck!

Dan

[Bob_Schor]

Found the manual.  Here is a summary (Edited -- actually, this is essentially the entire manual, just condensed and without "pictures"):

• Instruction format:  Prefix, Instruction, Data Frame, Checksum
• Command:  Prefix is 0xFE
• Response:  Prefix is 0xFD
• Add at least 50 msec between pairs of bytes
• Data Frame, send High, then Low byte
• Checksum = sum of Instruction, Data Frame, but not Prefix
• Commands and Responses appear to be mainly 6-byte sequences
• Hello:  Command 0xFE 0xA0 Null Null Null CS (Checksum).  Response 0xFD 0xA0 <P1> Null Null CS where P1 0 = OK, 1 = Fault
• Get Info: 0xFE 0xA1 Null Null Null CS.  0xFD 0xA1, <P1..P8> CS.  P1: Mode (1=A, 2=B, 3=C)  P2: Stirrer Status (0=Open, 1=Close)  P3: Temp Status (Open/Close) P4: Safe Temp (High)  P5: Safe Temp (Low)  P6: Residual Temp Warning (Open/Close)  P7: unused  P8: unused
• Get Status:  0xFE 0xA2 Null Null Null CS.  0xFD 0xA2 <P1..P8> CS.  P1+P2: Speed Set (Hi+Lo)  P3+P4: Real Speed  P5+P6: Temp Set  P7+P8: Real Temp
• Stirrer Control:  0xFE 0xB1 Speed(Hi) Speed(Lo) Null CS.  0xFD 0xB1 <P1> Null Null CS  P1: OK/Fault (0/1)
• Temp Control:  0xFE 0xB2 Temp(Hi) Temp(Lo) Null CS.  0xFD 0xB2 <P1> Null Null CS  P1: OK/Fault

That seems to be it.  Sounds ripe for a State Machine, which I'm happy to have Crossrulz explain.

Bob Schor

[crossrulz · Accepted solution]

---

@Bob_Schor wrote:

Found the manual.  Here is a summary (Edited -- actually, this is essentially the entire manual, just condensed and without "pictures"):

• Instruction format:  Prefix, Instruction, Data Frame, Checksum
• Command:  Prefix is 0xFE
• Response:  Prefix is 0xFD
• Add at least 50 msec between pairs of bytes
• Data Frame, send High, then Low byte
• Checksum = sum of Instruction, Data Frame, but not Prefix
• Commands and Responses appear to be mainly 6-byte sequences

---

Ok, that helps a lot.

First issue with the OP's code: turn OFF the termination character.  The protocol is using binary communication protocols.  The termination character is only useful for ASCII communication protocols.  Also not that if there happened to be a 0x0A in the data, the VISA Read will stop the read at that point because that is the termination character and it is enabled by default.

Secondly, still do not need the Bytes At Port.  You know what you are sending and you know what the response should be.  Therefore, just tell the VISA Read to read the needed number of bytes.  If your timeout is long enough, you also do not need the waits by telling the VISA Read how many bytes to read.

[Zergio]

Hey everyone its me again..

First I would like to say thanks everyone for the advices and the answers you guys wrote, i know that this program is not very well structured since it is the first one im working in but i will take your advices as future references.
Following the Dan's advice I got another cable but the problem persisted. And for the crossrulz's answer i turned off the termination character and added a flush at the end like Labuser16383 said, but still nothing after several seconds.

But somehow i managed to solve the problem, or at least thats what i think

This is what i did:
First, I decided to start from zero, so i took the Basic Serial Write and Read example in LabVIEW and i added a while loop to it, but it also stopped.

I saw a little time ago in another post that somebody did a modification of the Basic Serial Write and Read example, one that writes the command one  bit at a time or something, so i decided to add a while loop in it and it worked for several minutes with no problems.

So i decided to use this structure for my program and it worked for 50 mins before I stopped it. I'll include the final form of this code that works for me (by now), if somebody finds it useful. If someone can see a fatal error in it please let me know.

Greetings and thanks