Binary communication by serial port

[oloba]

Ah, that makes sense 🙂 Will move them outside, and put in some error-handling.

How do you mean close it "outside the loop"? And close what?

Is there anyway to, as in my second question, test signals i recieve and display them accordingly?

/Olof

[smercurio_fc]

Your VI makes no sense to me. Aside from the previous comments regarding the multiple VISA controls and having the initialize inside the loop, you did not understand what I had said in my response about reading 1 byte initially.

I don't understand what this is supposed to mean:

---

Also, the solution with the typecast and then remove the extra bytes that magically appeared might not be the best looking one... 😉

---

You VISA Read reads one byte and tries to convert this to an array. This makes no sense - it's one byte. In my example I read one byte to determine how many more bytes to read to get the rest of the message. You are not doing that at all. You VI will simply read one byte at a time at each iteration of the loop and always display an array with one element. 

[oloba]

Ah, sorry about that. I just changed it to receive one byte just to test it out. The parts inside the different cases works by themselves.

The read part reads one byte and displays it in the front panel. Updates when a new byte is sent.

The write part appends the length, pre-set info, and info, and sends it to the receiver (hopefully when I press some button).

The thing about the typecast:

If the length of the message is 5, I want the first byte of the sent message to be 0x05. I tried converting the output from the "get-length" to string, but then got the hex value of a decimal 5. So then I typecasted it to string, but then I got "00 00 00 05" in the beginning of the message on the receiver. So I just cut off the beginning to get it to start with 0x05. I just thought this wasn't the best looking solution, but it solved the problem for the time being.

[oloba]

I'm starting to see where you got confused by my typecast, apparently it didn't work the way I thought...

The one I have in the previously attached VI typecasts i.e. dec5 to 0x"00 00 00 05", then I just removed the first 6 zeroes and got it the way I wanted it.

When I tried your typecasting, to get it to pick out the first byte, then typecast it into a number and pick out that many bytes from the information sent, I have a problem. If I send 1 in ASCII, I get it as a 1 before the typecast, but afterwards it comes out as "822083584". I'm not sending that many bytes, so LabVIEW crashes.

I thought type cast just transformed dec5 into 0x05, and dec10 into 0x0A, but that doesn't seem to work from string to integer.

Also, I'm not sure what MattBradley wanted me to close "when you're done (AFTER the while loop)". It still times out when I try to send something from the VISA-write, even when I moved things outside the while loop. Also, the values received from VISA-read gets lost after some seconds, probably because it's still trying to read, but gets nothing.

Does this help, or should I try to explain it better? Attached the VI.

/Olof

[RavensFan]

You're having a problem because you are typecasting the single byte as a string to a I32 datatype.  You want to typecast it to a U8 datatype.  Change the representation of the blue 0 constant that goes into the top of the typecast to a U8.

[smercurio_fc]

As Ravens Fan noted, that 0 constant needs to be U8. If you go back to my example you will notice I placed a comment on the diagram indicating that constant needed to be a U8. There was a reason why I placed that comment there.

Matt is talking about having a VISA Close after your loop is done.

Additional comments:

• Instead of using String Subset for your write part, convert the string length to a U8. Then you won't need the String Subset.
• You have too many error indicators. Just use a shift register and stop on an error condition.
• Your loop should have a small delay to prevent chewing up processor time.

I do not know what is causing the timeout with your VISA Write. This may be an issue with the command you're sending. Perhaps it's not coming from the Write, but from the Read. Perhaps you cannot perform a read immediately after the write, and you need to wait a little.

Attached you will find a cleaned up version of your code with the correct U8 representation of the constant. 

[oloba]

Thanks, I couldn't find the U8 constant anywhere.

---

smercurio_fc wrote:
I do not know what is causing the timeout with your VISA Write. This may be an issue with the command you're sending. Perhaps it's not coming from the Write, but from the Read. Perhaps you cannot perform a read immediately after the write, and you need to wait a little.

---

Yeah, it is the Read that times out when I try to send. Also it times out if nothing is from the other computer. Is there anyway to counter this, except from raising the time-out limit?

Also, do you get time-outs when you try the VI, or is it only me? If you all get it, I might have to rethink how I want to do this. Is there any (hopefully better) way to do what I want to do? Maybe load things in a queue and then send them? Though adding queues will probably make it a bit more complicated 😕

[smercurio_fc]

Use the VISA Bytes at Serial Port (Instrument I/O -> Serial -> Bytes at Port) to first check if there's any bytes to read in the first place. If not, skip the read. I cannot run your VI since I don't have your hardware.

[oloba]

How do I skip the read? I'm having trouble finding anything to replace the programming "if". Case structures seems to be the closest, but should I implement one more of those?

Edit: It seems to be sending alright if I receive something the moment after I try to send. So if I spam the read, the write can send. Might this help finding a solution?

Message Edited by oloba on 04-01-2009 09:09 AM

[smercurio_fc]

---

oloba wrote:

How do I skip the read? I'm having trouble finding anything to replace the programming "if". Case structures seems to be the closest, but should I implement one more of those?

---

Yes. A case structure. Basic (non-LabVIEW specific) programming principle.

---

Edit: It seems to be sending alright if I receive something the moment after I try to send. So if I spam the read, the write can send. Might this help finding a solution?

---

I have no idea. I do not have your instrument or the manual, so I do not know how you're supposed to communicate with it. Does the manual say that it always sends out data, or does it send it out only when you send specific requests? If it's the latter, then it doesn't make any sense to be continuously reading from it, now does it?