07-15-2015 05:21 PM - edited 07-15-2015 05:22 PM
@Bob_Schor wrote:
Sorry, didn't notice the question -- BS Best is the last "Conditional-reassembly" example (you suggested it, as well, Christian ...).
What is the average length of your none-empty strings?
It seems we can speed it up a bit by not dragging the string through the conditional tunnel. Not sure why that is.
07-15-2015 07:15 PM
The string length is different for each serial port, and for port 1 and 4 the message length is variable and therefore not possible to predict.
Port 1: string length is between 40 and 64 characters
Port2: string length is 19 characters
Port3: are only individual bytes, there is no line termination to parse
Port4: string length is between 38 and 50 characters
Below is a screen shot of my code for parsing the U8 byte array and turning it into a string based on line termination, sorry for the image size I'm using 4K displays for my workstation.
I'm planning on implementing your conditional for loop solutiion within the individual for loops for each port. Based on your code snippet my plan is to:
1. remove the case stement for the "Elements Remaing" in the DMA fifo for each port
2. change the outputs to conditional terminals and check for empty strings within the for loop
by checking for empty strings in the for loop that parses the U8 byte arrays, im hoping that the performance hit should be negligible to changing the diagram to your second solution where the string data is not passed through the conditional tunnel. Based on your benchmarks im confident the system would meet my performance requiremetns.
My hope is that this would eliminate the empty cells in my TDMS file, the attached screenshot shows a depiction of the current tdms file. Column 1 is port 1, column 2 is the time stamp for port 1, etc...
07-15-2015 08:15 PM
As I explained, I generated uniform random integers from 0 to 9. If you remove the 10% (see my reports showing a good approximation of 90% remaining) with zero length, then the average string length was 5.
It is easy enough to change the algorithm for generating strings and run my tests again. I'm up for it if you have a specific distribution you'd like me to test (it will obviously be easiest if you allow me to specify a uniform string from 0 to N (like I did previously -- very little code to change ...).
Bob Schor
07-16-2015 12:22 AM
I'm confident your solution will provide the optimal system performance based on your benchmarks, I don't need testing with larger strings. Thank you though.
I was stating my idea in the event that the forum may have a more concise or efficeint solution, I'll post my implementation of your string parsing algorhithim once I'm able to conduct some system testing.
07-16-2015 12:57 AM
@VicEngineer wrote:
Below is a screen shot of my code for parsing the U8 byte array and turning it into a string based on line termination, sorry for the image size I'm using 4K displays for my workstation.
It is hard to understand your code from a truncated picture, but there are quite a few things that puzzle me. What is the datatype of the "data" array? Is it I8? (obviously it is not U8, because there is coercion). Wy are you building each element into an array just to use "byte array to string"? Couldn't you just typecast it? (Of course if the "data" array elements are more than one byte, you are throwing away information. So what is it?
Upper right: Why are you reading the AFTU global twice in a row. wouldn't once be enough?
Where exactly do the empty string elements originate?
If you leave the input to get date/time string unwired, it uses the current time. No need to clutter the diagram with "get data/time in seconds".
Couldn't you combine some of the inner case structures, they depend on the same boolean!
My gut feeling is that the entire code could be streamlined much better and made more efficient. Why are you converting to strings so early? Wouldnt it be more efficient to do all the processing on the blue data?
07-16-2015 03:44 PM - edited 07-16-2015 03:48 PM
We're in the midst of a testing phase right now, the Instrumentation Engineer when we were testing on Monday imposed several last minute requirement changes which is why this code is all hacked and slashed together. I hadn't had a chance to go back and clean up the diagram logic, and data flow.
I'll answer your questions as best I can.
1. Data Array, is U16, previously I was joining a lower byte to the data to indicate wheter the data was for Port 1, 2, 3 or 4. The performance of this in the RT application was insufficient so the code was modified to have a individual DMA fifo for each port. I neglected to change the data type of the FIFO's to U8 when I made the change. Each FIFO will have its data type set to U8.
2. Previously the data written to file was U8 Characters, a change was requested to store the data as Strings during testing. This was my 1st attempt solution, it will be changed to a typecast. Information will not be thrown away since all the captured data is U8. Answer 1 explains why the data in the screenshot is coecred
3. Yes Once is enough, I was having a race condition occur where when I set a local variable to True in another Asynchronous loop the data from "AFTU" was being read befor it was set. I changed the code to test if there was any data in AFTU which rectified the race condition. I had just negleted to add a tunnel into the case structure for passing the variable. It has now been rectified to only read the variable once.
4. The empty string elements originate from the "False" case for testing the end of line character. There is no wire connected so the "default" of the string output is used, thus empty string elements were being written to the 1D String Array.
5.I was not aware that the if unwired the "Format Date/Time String" function would use the current system time. ~ now changed, thank you for the information
6. The inner case structures have been combined, again this is due to rushed coding, with other engineers looking over my shoulder.
7. Do you mean parsing the U8 data, into a byte array looking for an end of line character then converting that byte array of U8 into a string?
ps. your gut feeling is correct, first stabs at anything under pressure rarely result in optimal designs 😉
Hopefully that clears up most things up.