Binary communication by serial port

[oloba]

Sorry for being so full of questions, but I can't really say I have a manual. I'm programming the CPU I want labview to communicate aswell, so I'm kind of making it up as I go.. 😉

The basic idea I have is the one I tried to describe earlier. It will not receive data continuously, so after reading your advice, I implemented the "bytes at serial port", which I never would have found myself. I really appreciate all the help!

I actually got it working the way I want it (again...), so the next step is to implement some more send-cases. Besides the 3 cases I got (do nothing /  listen / write) I need to implement 4 more send-cases.

I'll try to describe the way I think it works, but there is one thing I can't really understand. Let's say "A" is the "bytes at port", and "B" is the send button, and they both generate T/F which I convert into 0/1.

If both are 0 I get case "0", this is also the default case.

If A is 1, and get case "1".

If B is 1 I add it to itself (becoming a 2 if T, otherwise 0, and get case "2". The reason case 2 is also case 3, is that if I send and receive at the same time, this takes me to case 3 first (send) and then case 1 (receive). I'm not sure why this works, it seems like it queues it in some way, but I'm just happy it works this way so nothing get's lost.

This way of doing it get's a little tricky now that I need 7 different cases. I doesn't seem optimal to do it the way I'm doing it now, is there any other basic way to do a multiple-case structure, that would work the "magic" way mine does now (as in no data get's lost, operations just get queued)? 

I have two ideas on how to maybe get it work, apart from trying to add them the same way I have the other 3 cases. I could try to create some kind of MUX, and convert the T/F into an array, or I could use case structures in case structures 7 times. Both of them seem kind of bad, and I'm not sure this would keep the queuing of commands that appeared.

Felt like an essay for an easy question, but I hope I was more precise this time 🙂

/Olof

edit: VI attached

Message Edited by oloba on 04-01-2009 07:17 PM

[oloba]

I can't edit nor delete the last post.

After actually using my brain I realized I can do 7 different case structures inside the whileloop, each connected to the corresponding boolean-button.

[RavensFan]

Be careful the case structure in the VI you posted.  It is not going to work like you think.  You are taking a singe byte called address.  I am going to assume it is either a hex 01 or hex 02.  (Or \01 \02 if the string indicator is in \codes display").  But your case structure has cases for "\01" and "\02".  They are actually 3 bytes consisting of the characters backslash, number zero, and number 1 or number 2.  A single byte will never be equivalent to either of those.  Your best bet is to typecast that single byte to a U8 and wire that to the case structure so that you can have a case 1, 2, or default.

[oloba]

Hmm. It is working though. When I send 0x01 or 0x02 it displays it in the right indicator. I didn't manually type in "\01", I copied and pasted the ASCII sign for 0x01, and it translated to that in the case-window automatically. Might it be that labview interprets it this way anyhow, or should I change to be sure?

Also, Is there anyway to bind text-buttons on the front panel to the arrow-keys or w/a/s/d? I can only find keys like "insert", "end" and so on in the keybindings.

/Olof

[oloba]

I must have filled some kind of edit quota, or quota of stupid questions...

Anyhow, I was wrong. It's working alright when I send i.ex. 0x03020101 (length: 03, Address: 02, Data: 0101), but If I try to send 0x03020A01, it bugs out. 0x0302010A works though.

When it bugs out, it reads 0x03020A01 as 0x01020A, but nothing after. Next time I try to send  0x03020A01, it reads this as 0x020A01, and if I do it a third time as 0x01020A.

I typecasted the address byte into U8, connected it to the Case structure, and for cases set "1", "2" and default. Not sure if I should have the radix set for binary and type in "00000001", but this doesn't solve it either.

[smercurio_fc]

You need to rethink your architecture. The design you had was OK if you were just doing a simple read/write, but you are now tyring to create a "real" application, and the architecture you have will not easily support what you want. That is why you are having problems envisioning what to do. You should look into using event structures that respond to events. The ideal solution is to use a producer-consumer architecture, although you probably don't need to go that far if the sole purpose of the VI is for communication. 

It's still not clear what the relationship is between write and read, though you indicated that you will not be performing a read continuously. This implies that a read occurs only after a write. If this is the case then you should create a "read" VI that gets called after each send. 

[RavensFan]

You're right, the case structure does work with the \01.  It must be interpreting it as slash codes rather than 3 characters.  I have never found a reason to wire a string to a case structure, so I've never discovered these quirks before.

Converting to U8 and making the case structure based on 1, 2, default should work just fine and that is the method I would prefer.  It wouldn't matter if you set the radix on the case structure for binary, hex, or decimal.  I'm not sure how you know what you are reading vs. what you are writing and how your read strings relate to your write strings.  You must just be having a communication problem in that you aren't sending the bytes you think you are sending, or you are not reading all the bytes at the beginning or end.  You'll just have to continue to work on that and figure it out.

You can't bind the cursor keys to controls.  If you want the cursor key to do something, you may have to set up an event structure to handle a key down event for each of those keys.

PS.  Also check your spelling in your VI, as you have several words misspelled.  "received, address, these" are how they should be spelled.

Message Edited by Ravens Fan on 04-02-2009 10:14 AM

[oloba]

Sorry about the spelling, I changed it from swedish to english in a hurry to upload it here.

0x0A is defined as the default termination char, and as I hadn't changed any settings, my VISA terminated the read upon 0x0A being received.

Thanks for all the great answers! I actually looked into a producer/consumer model before starting, but it seemed to advanced. I'll try to rethink how I should build it then, maybe using sequences.

[smercurio_fc]

---

@oloba wrote:

I'll try to rethink how I should build it then, maybe using sequences.

---

Do not get stuck on the crutch of sequences. They only occasionally need to be used in LabVIEW programming.