PA-Paul Posted February 5, 2009 Report Share Posted February 5, 2009 Hi All, This is my first post here, so please be nice! I'm trying to write a device driver in Labview 8.6, to control a device via standard RS232 serial comms. I have the basics down but am looking at the best way to "decode" the data I receive from the device. The overall communications set up is simple, I send a byte array corresponding to the following format: END LGT OBJ PID OII VAL CHK END (The overall meaning is not hugely important here, but basically the OBJ and PID bytes define what the command is I'm sending. Basically, the OBJ defines which command set the command I'm sending is from and the PID value identifies the command in that set.) And the device sends back a response in a similar format. I've written a VI which sends data to the laser - using a text ring control, set up with a text description of each of the commands and the corresponding 16 bit integer value (OBJ and PID combined). I select the command I want to send from the ring and it returns the appropriate number which can be turned into an array of 8bit bytes which can then be inserted appropriately into the command string I send the device. The device responds to each command with a similar byte array again containing the OBJ and PID bytes... I now need a sensible way of converting those bytes back to something more useful (for example a text based description of the reply and other relevant info such as units and things!). I did wonder if the best thing to do may be to build some kind of look-up table based on the values that could come back, but I'm not sure how efficient that really is (or the best way to actually do that!). One alternative I did think of was to use the original text ring that I used to send the commands - by feeding the combined OBJ and PID bytes back to the ring in indicator mode, I get an "indication" of the command that has been executed. I can then use a property node to get the actual text used in the ring for any given command. BUT... this would mean that my supposedly low level VI is having its diagram loaded into memory all the time because of the property node - does this happen even if the indicator is hidden? Is this such a bad thing anyway? IS there a more efficient way of turning the returned bytes into something "more useful"?! (Just for added info, the PID byte also tells me how any values are coded and if the previous command caused a change (i.e. if I sent a write or query type command), hence there's more info than just the command name in it!). If anyone can point me in the right direction on this, be it pre-existing examples or just basic advice, I'd appreciate it! I know I can "make it work", even if I resort to using a nested case structure (top level for decoding the OBJ byte and inner for the PIDs), but I to do it "properly/well"! Thanks in advance for any help! Paul Quote Link to comment
crelf Posted February 6, 2009 Report Share Posted February 6, 2009 QUOTE (Ic3Knight @ Feb 4 2009, 04:46 PM) This is my first post here, so please be nice! Welcome! QUOTE (Ic3Knight @ Feb 4 2009, 04:46 PM) I'm trying to write a device driver in Labview 8.6, to control a device via standard RS232 serial comms. I'm pretty sure I know what you're asking, but it's best if you upload a code example that we can discuss. Quote Link to comment
JustinThomas Posted February 6, 2009 Report Share Posted February 6, 2009 The lookup table does look like the obvious choice here. If the amount of data to be stored in the lookup table is significant you should try using a file. An INI or XML based file would be ideal. Having said this a better suggestion can be made if you can upload an example of your code Quote Link to comment
jdunham Posted February 6, 2009 Report Share Posted February 6, 2009 Also, if your commands don't change, you should use an enum rather than a ring. Then you don't need a property node, because you can use the OpenG "Get Strings From Enum" VI. Also, don't worry so much about 'efficiency'. Just make your code readable and maintainable. An RS232 instrument is going to be orders of magnitude slower than your LabVIEW program, so your program's speed will be throttled by the comms. Who cares if the rest of the processor cycles are taken up with some LabVIEW you could have improved? Quote Link to comment
PA-Paul Posted February 6, 2009 Author Report Share Posted February 6, 2009 Hi all, Thanks for the replies. I've attached the current version of the VI to read and decode data from the device to this message. Just to add an answer to jdunham, I can't use an enum since the numeric values are not a consecutive set... For info, the text ring is usually a strict type def, but I disconnected it in the version I'm sending here (I wasn't sure if, leaving it defined would mean that I had to upload the ctl files as well...). Thanks in advance for any input! Paul Quote Link to comment
PA-Paul Posted February 10, 2009 Author Report Share Posted February 10, 2009 Hi all, Not wishing to rush people, as I realise people have their own work to do! but I was just wondering if any of you who've downloaded my VI have had a chance to look at it, and have any comments? (I'd be interested in general comments as well as anything relating to my original question!) Thanks!! Paul Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.