12-07-2015 08:52 AM
I'm hoping someone here can point me in the correct direction.
I am trying to develop an alternate test solution for the COTS program Accessport (http://www.sudt.com/en/ap/) in Labview. I found a basic serial communication example that I was able to manipulate and display my data stream (32 HEX bytes, 69 being the start byte):
Where my problem lies is in the data stream. This basic example is displaying the data as a string type in that "read string" textbox. I need to manipulate that string data and break-out/display individual bytes, and I'm not sure really where to start. I tried adding a table....but I'm getting a data type mismatch in the Block Diagram.
Eventually, I'd like to be able to select / monitor only specific bits, and let LabView handle the data processing....but I'm getting ahead of myself. Thoughts?
Solved! Go to Solution.
12-07-2015 09:11 AM
Please attach your image to your post rather than using a 3rd party hosting site. Those are often blocked in corporate IT environments.
If you want to convert a string to an array of bytes, the function is called String to Byte Array.
12-07-2015 09:17 AM
If you know the exact format of the data, then you just use String To Byte Array and then Array Subset or Index Array to get the sections you want. You could also just use Unflatten From String with a cluster to represent all of the data. This second option works well for protocols that do not use bit packing.
But we can't really help any without knowing what the protocol is.
12-07-2015 12:46 PM
Yea, sorry about the external link to that picture. I just didn't know how else to do that, because the second image was coming-up with a broken "X" every time I tried to upload it.
To the next point, the protocol...I'll have to get back with you on that one I have that question out to the design engineers, but they kindly gave me a table which defines the entire data stream down to individual bits. They said that the important part is that the "reader" syncs on the byte0 "69". The end goal is to have a reader interface, where an end-user can select an individual function bit (or group of bits/bytes), and monitor the data real-time as switches are being thrown.
Where I'm struggling at the moment is that the data is not populating an entire row.....it just goes straight down one column, and every time I try to resolve it, the Block Diagram gives me a warning that I'm trying to put 3d data into a 2d array?
I have attached my current project, if it helps?
I also found another Thread in the forums, that seems to be the same question as mine....but I'm having trouble determining what the end solution was:
12-07-2015 12:50 PM
Don't use build table express VI and don't use the blue dynamic data type wires.
Just use the 1-D array that comes out of the string to byte array. If you need it to show as multiple rows, then use Build Array to turn a 1-D array into a 2-D array.
12-07-2015 02:47 PM - edited 12-07-2015 02:48 PM
To answer a previous question: Comm Protocols -
TIA/EIA-422 is the electrical interface specification
ANSI/TIA/EIA-404 is the signal architecture specification - specifies the data byte structure
I have not had time to pull these documents myself & review, so please forgive my ignorance...
Back to the VI, getting closer. I can at least review my data now. However, I used an appended array.....so all the data is on a single line (usually 72 or 108 bytes). I need to limit the array width to 36 bytes.....then try to increase the overall bytes that are pulled-in to fill-out the array 36x10. Would be nice to be able to sync on the 69 "start" byte every time....but I'll take the little victories at the moment.
Attached the latest VI.
As an aside....may need to open another topic for this one...but I'm getting an intermittent VISA framining error. I put-in some error handling to try and dismiss, but my code is executing after the error has already stopped execution.
12-07-2015 04:57 PM
Framing errors are often related to incorrect serial settings such as wrong parity, or wrong number of data or stop bits. Double check those settings.
Don't reconfigure the serial port and close the serial port in every iteration of your while loop. The configuration should be before the loop, the close should be after the loop. Only do the reading in side the loop.
"Bytes at Port" is almost always the wrong method to use when reading serial ports. Since you know that you are looking for 36 bytes every iteration, just read 36 bytes.
Framing of the 36 byte packages (not talking about serial port framing errors here), can be tricky. If you are looking for the start byte of 36, you could read the port 1 byte at a time until you detect the byte is 69. Then proceed to read 35 bytes.
12-08-2015 05:56 AM
Yes, I'm going to work on that port configuration today. That was part of the example VI that I was not happy with.
12-15-2015 08:05 AM - edited 12-15-2015 08:11 AM
Sorry, I got sidetracked a little bit, and did not get back to this as intended. I have attached my latest file, with an example data stream text file to place in the Send box. If you have a PC with a serial port, and a loopback cable....you should be able to run this VI (you'll likely have to change the Com Port and Baud rate to match your system).
Where I am at the moment:
1) I am still trying to set-up an rolling table which displays the latest 11 rows of 36 bytes. Right now, I know that it is not correctly configured....it is only reading-in the same test pattern, then deleting the first row each execution. I wanted something working to post out here.
2) The actual units spit-out 2-4 rows of data each time the VI while loop executes (I don't believe there is currently any data loss). I'd like to buffer the received data in a 60-row array somehow, so that about 15 seconds of data captured for the user.
3) I'm still getting some sync issues with the Units. as configured, the VI usually picks-up on the 69 start bit....but it does skew every so often, and then syncs back up. Would be nice if the VI could detect the 69 start bit, before recording data to the output array.
4) Is is possible to create a moveable & resizeable GUI slider to Highlight and/or Block-out colums of Data?
Given time, I will figure these out on my own....I'm just looking to shorten my learning-curve with your help. 🙂
12-15-2015 08:45 AM
1. Reshape array is wrong. And the steps through the shift register aren't doing anything for you other than delaying all of those manipulations.
You want to add every 36 bytes, build that into an array. Then remove the oldest rows using delete from array.
2 and 3. You are using Bytes at Port which I told you is the wrong thing to use. I described a method for how to find the start byte. See my attached VI where I implementd that.
4. You could create a front panel object, perhaps a picture indicator or color block that you size to cover a column. You can use mouse drag events on that control to detect where to move it to. That is really a whole separate question beyond the serial parsing.
Also, you have your string to write set as *IDN? (It was converted to hex display so it wasn't that obvious.) Are you sure that is what you want to write? That works for instruments such as spectrum analyzers, power supplies, DMM's. It is built into the serial examples, but often that command means nothing for most serial devices you'd talk to.
You also had the termination character enabled. That means any time you'd get the termination character (line feed hex10), the serial read will shorten. That is why you think you're getting skewed data. When you are working with binary data, you should disable the termination character and use other methods (like a defined packet size of 36 bytes) to determine how much to read.