LabVIEW
VISA Package Error
Good afternoon. Please tell me if I have encountered a problem that data transmitted from the device sometimes comes with a delay or error. It may mistakenly look like CT2560 S1.000 I045, C25602560 S1.000 I045. 5, C T2559 559 S1.000 I045, etc.
Could you give me some tips or suggestions on my VP? How can this be fixed, because all such moments are clearly visible in the graphic part.
It doesn't look like you are writing anything, so I would remove that part. There is no point for the wait, so get rid of that. We know you always want to read, so remove the case structure. A little more clean up and I am left with this.
This was the very first option, but it's just a simplification of the code. Not exactly what I need. Let me try to explain the essence of the problem in more detail: I use the delay that is in the frame to more correctly reflect the data transfer speed in the XY Graph, so it stands between the frames where VISA Write and VISA Read are used. VISA Write is really not set up right now, as I ran into the problem described above. If you look at the figures where the graph is presented, you will see that in some moments there is a jump, i.e. the data entering the graph are like, for example, 2588, 2589, 2589.., 255(0), 2589.. (Just 255 or 0 is an error of the non-correct packet from the device). I just need help to fix this problem. My attempt earlier was to catch this erroneous line and exclude it (ignore), but as you can see again on the chart, this did not bring results.
Hi Seth,
@SeraphimSeth wrote:
My attempt earlier was to catch this erroneous line and exclude it (ignore), but as you can see again on the chart, this did not bring results.
That's what I would consider as a quick (and dirty) fix, but apparently you didn't implement the fix correctly…
How do you determine invalid messages and how do you exclude them from plotting?
@SeraphimSeth wrote:
I use the delay that is in the frame to more correctly reflect the data transfer speed in the XY Graph, so it stands between the frames where VISA Write and VISA Read are used.
The rate of the data coming over the bus is what you actually care about. Therefore, any delay in your code pushes the data out in time. And if the data is coming out quicker than your 100ms, you will get behind. By getting rid of the wait, you are relying on the termination character being read to know when data is there, which will match when the device sends out a complete message.
@SeraphimSeth wrote:
Please tell me if I have encountered a problem that data transmitted from the device sometimes comes with a delay or error. It may mistakenly look like CT2560 S1.000 I045, C25602560 S1.000 I045. 5, C T2559 559 S1.000 I045, etc.
Thinking about this a little more, it is sounding like something is happening in your device. It is sounding like a command or some condition caused it to freeze and/or stop sending data.
It is also possible you have a noise issue that is causing the data on the cable to be noisy and therefore not register bytes to the UART in the computer.
Do you see this if you use a terminal application such as Putty?
Hi Seth,
@SeraphimSeth wrote:
But even with the C\sT%d\sS%f\sI%d format, any of the following lines gives an error
(CT2560 S1.000 I045;
C25602560 S1.000 I045;
5; C T2559 559 S1.000 I045;)
See this:
Your 2nd example line is invalid because of the missing "T" char, so it doesn't appear in my resulting array…
In the end I would search for errors upstream: why do you get invalid message responses at all?
