Using comport data to start a sequence

[RavensFan]

You could do the read and wait for a smaller number of bytes such as 600.  Append the data together.  Once you have 60,000 bytes, then move onto the next state of parsing.  Since the read state would be running much more frequently, the clock in that state will update more frequently.

[ssmith490D]

We have our number all mixed up. The 60,000 was originally for the timeout of the read, 60 seconds.The actual byte count is 401 for each data transmission/ LV read. The data comes in to slow to read one byte a time so the clock can update. Can I run the clock independently of the read case?? The clock isn't used for timing in the program just as a fromtpanel display. Thanks.

Scott

[RavensFan]

Yes.  It could definitely be a parallel while loop to update the clock.  I don't understand why you did not have success with it before.

Please try again and post your code with any explanation as to how it is not working correctly for you.

[ssmith490D]

Ravens Fan

        I've attached my current version of the program. You mentioned previously to put the Configure Serial Port.vi in the initialize case and the Close.vi outside the loop. I tried this and it did not work properly unless the data stream is connected to the com port after the program is started. Putting them all in the same case ensures that no data will be in the port buffer when the program starts and thereby screwing up because I'm only reading 401 bytes at a time. Right now it works fine except that I need a stop button for each loop. I tried wiring a single control to both loops and got varied results. If the control is outside the loops it never gets read once the program starts. If it's in the read case the clock only updates when the program leaves the read case, which is once every 10 seconds and will eventually be once per minute. If I put in the while loop with the clock function data never gets read. Is there a way to stop both loops with one button?? Or will I need 1 stop button for each while loop?? Thanks for the continuing help.

Scott

ssmith@bnl.gov

[RavensFan]

---

ssmith490D wrote:

        I've attached my current version of the program. You mentioned previously to put the Configure Serial Port.vi in the initialize case and the Close.vi outside the loop. I tried this and it did not work properly unless the data stream is connected to the com port after the program is started. Putting them all in the same case ensures that no data will be in the port buffer when the program starts and thereby screwing up because I'm only reading 401 bytes at a time.

---

I don't understand why you say this isn't working properly.  If you continually open and close the port, then you are throwing away data in between.  But if you say it is working for you this way, go for it.

---

ssmith490D wrote:

Right now it works fine except that I need a stop button for each loop. I tried wiring a single control to both loops and got varied results. If the control is outside the loops it never gets read once the program starts. If it's in the read case the clock only updates when the program leaves the read case, which is once every 10 seconds and will eventually be once per minute. If I put in the while loop with the clock function data never gets read. Is there a way to stop both loops with one button?? Or will I need 1 stop button for each while loop?? Thanks for the continuing help.

---

Yes, you can stop both loops with one button.  You'll have to change the operation of the button from latch when released to switch when released.  Then create a local variable of that control to use in the other loop.  Of course the button will not reset itself once its been read (which is what the latching action is, and you can't do because you are reading in multiple locations, which read would cause it to reset?).  So what you can do is create another local variable you can write to where you set it to False once both loops have ended.  This is where a flat sequence structure is handy.  One frame contains the while loops.  The next frame writes the false to the stop button to reset it before the program ends.

[ssmith490D]

I made the changes you suggested. When I ran the vi I received a "Fata Internal Error:memory.cpp", line 638 Labview version 7.1" error. I don't know if it's related to the changes. Ever seen this before??

Scott

[RavensFan]

I don't think I've seen that error before.

You can search the forums for that http://forums.ni.com/ni/search?board_id=170&submitted=true&q=fatal+error+638.  There are numerous hits.  Maybe one of those will apply.  Many of the links talk about problems with .dll's.

[ssmith490D]

RavensFan--

      I've read the threads regarding this error and apparently there is no single answer. It also seems that this issue is a bug in LV7.1 and earlier. I'm using 7.1, lucky me!! I have backtracked and have determined that the error occurs when I add the parallel while loop that the clock is in. Looks like i'll have to let the clock update once per minute with the read case unless you or someone else has a better idea. Thanks for the help with this problem.

Scott

[ssmith490D]

Ravens Fan--

        Happy Holidays. I wanted to thank you again for the help on this. After reading a bunch of other posts related to serial bytes at port I came up with a solution. If you recall the original problem was reading a comport without continuously looping through the program waiting for data to arrive. So I use "VISA Wait on event" , use serial character as the event. Then use a property node to monitor the bytes in the port. Wait 20ms and look at the number of bytes in the port and compare the number that was there in the last iteration of the while loop. When 2 consecutive iterations have the same number of bytes that means that the data message/transmission is complete and program exits the loop and goes to the read and then continues. I've attached a jpg of the section of code to show what I've done. Thanks again.

ssmith

[altenbach]

---

ssmith490D wrote:

I've attached a jpg of the section of code to show what I've done. Thanks again.

---

Can you attach the actual VI please?

In your earlier incarnation of the program (CR23x.vi), you make some serious coding misteps that you should address.

• Never use "Path to string" and "string to Path" unless you have an OS specific function. Exclusively use "Built path/strip path"!
• You have tons of hidden arrays for the sole purpose of servicing local variables. Not only are you constantly reallocating the arrays due to resizing, you also constantly create extra datacopies in memory due to the local variables. This is extremely wasteful. You can eliminate all the hidden controls and use a few shift registers instead. Maybe 3 shift regsiters are all you need. a 2D array for the data, A string for the "read buffer", etc.
• Your arrays grow without limits. It would be better to allocate a fixed history size and replace data as you go.
• It seems you fixed that in your latest version, but that small while loop on top is appending time values at a much faster rate than the data in the lower loop and you immediately get a mismatch between the two.
• The data file should be opened only once before the loop, and not with each write operation. Use lowlevel file IO.
• ...