02-13-2018 01:20 PM
Hi Guys,
Quick rookie question.
I'm transmitting data over RS232 and I've formatted it like S: (decimal), MA: (decimal), P: (decimal),
(no space between colon and the bracket, added to avoid emojis)
The transmission script in my controller is coded like this: \n being new line.
print ("S:", Speed," ,\n","MA:", MotorAmps," ,\n","P:", Power," ,\n\r")
This is a cyclic telemetry i.e. it gets repeated every 50ms.
I receive this data using NI VISA, all seems good when I probe on the Read VI in the same loop. Refresh rate is the same too.
This is the probe data that I get:
+
+
S:0 ,
MA:2 ,
P:8 ,
S:0 ,
MA:4 ,
P:6 ,
VI (Attached)
I've tried one single string and other ways but can't get around it.
This one however works better but the string output takes atleast 3 times more to refresh. As if the scanning of the string isn't happening as fast. Some times there are misses and mixing of values too.
Any useful advice would be appreciated.
The goal is to get individual values of S, MA and P and later use them.
02-13-2018 01:40 PM
I've tried one single string and other ways but can't get around it.
This one however works better but the string output takes atleast 3 times more to refresh. As if the scanning of the string isn't happening as fast. Some times there are misses and mixing of values too.
Can you clarify the bolded points?
You are not handling errors, so how do you know if your read function is timing out or not? Why are you using the feedback nodes?
02-13-2018 01:44 PM
wrote:
VI (Attached)
.
No, that's just a picture with overlapping objects and thus hard to follow. Please attach the actual VI!
Your use of the feedback nodes is wrong. At least you should branch to the indicators before the FN. to prevent delays. What's the purpose of the feedback nodes?
Why don't you simply search for the various tag strings and parse the immediately following number as plain numeric?
You have some coercion dots. Why?
You have no pacing. What would be a reasonable loop rate?
How do you stop the loop?
02-13-2018 01:47 PM
Hi sytronics,
VI (Attached)
There is no VI attached, just an image of a small part of a block diagram…
(We cannot debug or run images with LabVIEW, but we could with VIs.)
I receive this data using NI VISA, all seems good when I probe on the Read VI in the same loop.
So what is your problem? You don't mention any errors…
Did you set the CR ("\r") as TermChar? Then you would receive the full message in one string!
Parsing the full string:
(There are surely "nicer" ways using RegEx…)
02-14-2018 06:36 AM
@GerdW wrote:
Hi sytronics,
VI (Attached)
There is no VI attached, just an image of a small part of a block diagram…
(We cannot debug or run images with LabVIEW, but we could with VIs.)
I receive this data using NI VISA, all seems good when I probe on the Read VI in the same loop.
So what is your problem? You don't mention any errors…
Did you set the CR ("\r") as TermChar? Then you would receive the full message in one string!
Parsing the full string:
(There are surely "nicer" ways using RegEx…)
Ah sorry guys, I thought I selected the image along with the VI.
Will attach once I get to my workstataion as the VI is there.
Again apologies if I didn't explain the problem well.
Up until the read VI, msg is coming in fine. So the problem is that I'm not parsing the data right.
I couldn't get the intended results when I used help and "what expressions are allowed" using the scan for string VI, regex formating.
I did manage to get S: value like it's shown in the OP attached image. The problem with it was that the value wasn't refereshing fast enough i.e. fluctuating between 0s and the current value. This is where I thought of using a feedback node in order to hold the previous value. Just to double check if the read VI wasn't timing out, I had the probe screen with the probe on Read VI and the values were coming in at the right rate inside this loop.
Over a longer period I also noticed that S: started to occasionaly pick up values from MA:. This meant I was doing something completely wrong as if the scan wasn't tight enough and picking up other decimal values within : till , from other parameters.
I'll try the above and see if it works.
But thanks guys hope the above makes sense!
02-14-2018 12:13 PM
Several suggestions:
Bob Schor
02-14-2018 12:26 PM
@Bob_Schor wrote:
Several suggestions:
- It will be a lot easier to run/parse/debug if you send all of the data in a single line, e.g. print ("S:", Speed, ", MA:", MotorAmps, ", P:", Power, "\r\n"). Now a data line looks like S:0, MA:2, P:8<cr><lf>. Note I wrote <CR> before <LF>, as this is the usual convention.
- Configure your VISA device to use a Termination Character (like <CR>, but <LF> will also work). When you do your VISA Read, specify 100 characters (more than you need) -- it will read to the Termination Character and stop.
- I like to use "Scan from String" to parse things. It can do it "all at once", and if the string is mal-formed, can generate an Error (when I ran the example below, there was no error, S held 0, MA held 2, and P held 8).
Bob Schor
Hi Bob,
Thanks for your suggestions there. This surely will help me form a better string to send across.
I had it as one string initially but went for individuals afterward, no particular reason though.
Now here's an interesting thing which you guys might have picked from the orignal post about the incomming string.
The controller that sends the string occassionally sends some ++ as to respond back i.e. ack. This doesn't affect the string itself but it's placement i.e. ++[complete string]++. Now since the refresh rate for the string is 50ms so these ++ flash up several times.
My understanding is that as long as the scan function scans for the the right order along with the string tags it should be fine, similar to the c equivalent of string compare, I might be wrong here.
02-14-2018 12:59 PM
Well, if you expect possible double-plusses in your string, you can always search and replace them with an empty string (an effective "Delete") ...
Bob Schor
02-14-2018 01:10 PM
Or just search for "S:" and scan from that offset with an appropriate format statement.