LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Removing Empty strings from 1d array


@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.

 

 

0 Kudos
Message 11 of 16
(1,975 Views)

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...

 

Serial loops.jpg

0 Kudos
Message 12 of 16
(1,946 Views)

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

0 Kudos
Message 13 of 16
(1,928 Views)

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.

0 Kudos
Message 14 of 16
(1,896 Views)

@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?

0 Kudos
Message 15 of 16
(1,883 Views)

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.

 Improved Serial Loops.jpg

 

0 Kudos
Message 16 of 16
(1,828 Views)