capturing data acquisition frames reliably at 100 hz using serial, how?

[CB]

Hi All,
I am completing development of a 14 channel, 10 bit resolution, pic based data acquisition circuit. It transmits frames of 41 bytes (currently) at 100hz using serial. The embedded code functions satisfactorily. I can see data ok using hyperterminal. I am unsure how to optimise labview to get complete frames without hogging lots of cpu/system resource etc. eg. do I simply set the frame size (num of bytes) to retrieve and set this looping as fast as possible , and/or set the rate to fetch frames at the rate frames are transmitted by the pic? This may allow drift in available buffered bytes to finally overflow the buffer.

I tend to lose 1 byte in 100 typically doing nothing but this increase
s to chunks of bytes if I interact with windows.

I have the feeling a number of decisions need making when setting up a serial link like this but I am unsure which settings best suit my application.

Thanks in advance,

Regards

Chris

[johnsold]

Try using a loop that only reads the serial port and transfers the data to a a separate, parallel loop for processing via queues. The read loop should check Bytes at Port and if > 0, then read all available bytes. The processing loop can sort out the frames (which should have unique delimiting characters). Put a wait in each loop. This causes LV's internal scheduler to share resources between the loops.

Also consider handshaking if avoiding loss of data is critical.

Lynn

[Tristan_J]

Chris,

In your current setup are you using a serial config and then a serial read of 41 Bytes within a while loop?

In order to help you debug this problem, could you post your code to the thread.

Kind Regards

Tristan
Applications Engineer
National Instruments

[CB]

Hi Lynn, Tristan,
Thanks for the helpfull comments. I have attached the llb I have started to use but its not very refined.

data is transmitted as ASCII - hexadecimal

Byte 1 = 0
Byte 2 & 3 = 8 bit frame counter
Bytes remaining are 10 bit numbers range 000 to 3FF
each 10 bit number rests against the number from the next channel, ie 140 bits for 14 chans.

I also attached a file containing frames logged from the circuit to HDD. The 200 or so lines of data look fine apart from a couple of glitches at the start, which is confusing as I see plenty of 0 byte frames when graphing in real time.

Thanks for the help

Regards

Chris

[johnsold]

In the Serial In.vi I would add an additional case structure inside the no error case. If Bytes at Port = 0, do nothing (except wait), otherwise read the bytes. That should eliminate the zero byte frames.

The ASCII 2 ints.vi only looks at the first 46 bytes. What happens to the data if some other number is read? If all the data read is concatenated into one string amd then parsed out one frame at a time, you may find some of your missing data. Getting the first frame is the tricky part since any ASCII character can appear in a valid data stream. Once you find a \n0 combination, see if the next one is the correct number of characters later. If so, your framing is established. Tracking the frame numbers will tell you if you have missed d
ata, since it appears that they are consecutive.

Lynn

[CB]

Hi Lynn, Tristan,
Please find the current llb attached. This has my last serial run and shows how the data gets glitchy after a number of seconds (toward end of the text box).

I have spent time building the suggestions into code. I am not yet trying to strip out individual channels. At the moment I just want to get frames in reliably before moving on.

It certainly looks a lot more reliable now but a few more questions have been raised. I think the idea of getting data in using 1 loop then immediately passing it for processing by another parrallel loop seems important for reliability.

You will notice I grab a frame and it then goes into a que where it will be processed but this needs doing quickly as frames will be used in realti
me.

I have set up the code to trim the delay for both the get data from serial port loop and get 1 entry from the que loop.

I am using 2 identical circuits in my product, 1 captures data from a leg harness, the other controls movements of a biped robot (servos) this occurs in "real time". I need to remove as much latency due to processing as possible.

click on "video 3" on the right of the page for a prototype demo:
http://www.robotic-systems.co.uk/products/full_system.htm

I noticed that some of text embedded within text boxes used in subvi's can tend to float thro to the top level vi. I proved this by adding a bit of text and noticed it kept cropping up occasionally on the top level text box. I found this peculiar but cured it by deleting all chars in the subvi text box. Now I am concerned, could this be somthing to do with why I get glitches in text occasionally?

Is there some labview feature to say flush all text, numbers and bools prior to running from the top leve
l?

I'd be gratefull if you have a look thro my llb and sanity check the flow of code and let me know what you think.

Best Regards

Chris

[CB]

Hi Lynn, Tristan,
I appears the loss of serial acquired data was due to a conflict between the 100hz acquisition of serial data and planting the data into a "screen" textbox, typically refreshing at 60 or 80hz. I am not sure of the precise technical explanation.

I made the updated textbox invisible when the program was run then made it visible to inspect the contents once I'd stopped the program. I couldn't see any data loss. I think this is the answer but a technical explanation would be appreciated.

Is there a way to retrieve groups of que elements rather than just retrieving single elements quicker. I imagine a block dump of que elements is much quicker than speeding up how often elements are returned.

Thanks for your help.

Rega
rds

Chris

[johnsold]

I see a few things which might help explain this.
1. Even though the screen may update 60-80 times per second, the human observer does not. Updating the displays 2-3 times per second is fast enough. Even then a user cannot really keep up if the data is changing rapidly.
2. Put the string into a shift register rather than using a local variable (queue ASCII).
3. Only read the queue and update the shift register/string and display if the number of elements is >0.
4. I generally prefer to put the Error clusters on a shift register unless there is a specific reason not to do so.

If you really do not need the data displayed until you have stopped the acquisition, put the queue ASCII indicator outside the loop.

As for retr
ieving groups of queue elements, the Get Queue Status function which you use to check the number of elements can also retrieve all elements as an array. You could then use array functions to get the elements you want. Note that you have to set Return Elements? to True and that this does not remove the elements from the queue. Queue primitives execute quite rapidly. I think you could get all the elements from the queue in microseconds if you put the Dequeue into a loop without a delay.

Lynn

[CB]

Lynn,
I have managed to get a reliable data stream now, I can see the data coming in at 100hz.

Many Thanks for the advice and explanation.

Unfortunately solving 1 problem typically leads me onto another. I now find the serial connection is causing a problem. When the pc is first fired up I can connect my hardware to the serial port and it functions ok. My remote pic hardware will function fine in logger mode for a few minutes then hang. Quitting labview and re-entering labview and running the logger monitor routine does not re-initialise the serial port. I am clutching at straws but could it be the flow control pins (or similar) are getting set somehow and locking up the serial port? ( I have some embedded code on the p
ic I didnt write which may be causing the conflict )

I have tried running the pic circuit on a laptop which has the same problem.

I also get similar problems when running the remote pic circuit in servo controller mode.

Is there a way to check these settings, I havent looked too closely but imagine I could put a vi together to monitor the various CTR, DSR etc? lines on the 9 pin serial port.

Help and advice apreciated

Regards

Chris

[johnsold]

Chris,

Welcome to the world of serial voodoo! Undocumented serial protocols are among the most aggravating problems faced by LV users.

Flow control is certainly a possibility. VISA property nodes allow access to them so you should be able to monitor them as you suggested. Another thing to check is termination characters. Verify that you are using the correct character \r or \n and that it never appears in the data. If the termination character can occur in the data stream, then disable Stop on Termination Character and handle the end of message determination some other way.

A good troubleshooting technique is to use a terminal emulation program. If it can reliably communicate for longer periods th
an your LV program, then the problem is with LV.

Also make sure that no other software on the computer can try to access the same serial port (like the OS looking for a printer). This can cause lots of mysterious problems.

Do you get any error messages when it stops communicating? Look at the last bytes received - Are they the normal end of a message frame or somewhere in the middle?

Good luck,

Lynn