LabVIEW
Scan From String cannot find values from a stream of strings
@crossrulz wrote:
@Bob_Schor wrote:
Remove the "Bytes at port" test, and ask VISA to read 1000 characters (up to the next \n). Your device is sending lines (probably with a few dozen characters) -- when you get a (single) line, go ahead and analyze it.
The check Bytes At Port test is fine. It is quite reasonable to check if a line has at least started to come in. Where I get upset is when people use the Bytes At Port to tell the VISA Read how many bytes to read. In this case, I would just increase the number of bytes being read to something more like 100.
A link to my presentation: VIWeek 2020/Proper way to communicate over serial
Fair enough. That sound's like a proper use case.
One problem with using Bytes At Port in drivers is that VISA can change from RS232 to USB or TCP\IP, but Bytes At Port doesn't.
This might seem unlikely to ever happen, but when moving to a cRIO we use a TCP\IP to serial converter and talk to serial devices over TCP\IP. Drivers using Bytes At Port would need to be refactored.
Wouldn't reading the data (\w termination characters!) with a time out of 0 be a similar trick?
Search LabVIEW like a graph!
@samAAF wrote:
wiebe@CARYA wrote:
@samAAF wrote:
Labview definitely has a steeper learning curve than other text-based programming languages.LIES! Blasphemy! 😆
Just kidding. Most people here would disagree though.
A steep learning curve isn't bad, if it's short 😊.
Well this would have been very simple in other text-based languages.
You don't know unless you try. 🙄
I'm sure you will run into unexpected problems that are only easy to fix when you're familiar with the language. I usually do...
@samAAF wrote:Well this would have been very simple in other text-based languages. I just need to scan the incoming strings find the start character "X" and then parse the remaining characters into a string var.
You could do it that way in LabVIEW as well.
The problem is, you have to do it the right way. In any texted based language (TBL), you'd have to do it the right way too.
In some TBL, you might have some benefit in using the serial data as a stream, and using functions like scan from string directly from the stream. That might make things a little bit simpler.
I still think sometimes that using a TBL would be easier for some problems. I sometimes try. I usually run back to LabVIEW with greater appreciation.
Besides DAQ, strings and esp. arrays (1D, 2D, 3D) are usually hell in TBLs.
@samAAF wrote:
It took me a couple of hours just to find the Select and Bundle functions.
I do hope you did some of the free tutorials.
Not that you'd know where to find everything after doing them, but usually it's a matter of knowing for sure there's some function and having some idea about the name (using QD) or palette location it's in.
@samAAF wrote:
Anyway thanks again you have been a great help!
You're welcome.
wiebe@CARYA wrote:
@samAAF wrote:
It took me a couple of hours just to find the Select and Bundle functions.I do hope you did some of the free tutorials.
Not that you'd know where to find everything after doing them, but usually it's a matter of knowing for sure there's some function and having some idea about the name (using QD) or palette location it's in.
To be much more specific here, QD means Quick Drop and you'll typically find anything within seconds, no matter how deep it is buried in the palettes. 😄 (Start reading here)
@samAAF wrote:
Well to use the QD first I need to know what the thing I am looking at is called. I think the QD is more for experienced users who at least have some idea what a function or part of it is called. It doesn't have contextual or relevancy search.
I agree, but it's still a powerful tool that's often worth a try.
Also note that the right click on a wire, then insert gives a context sensitive palette:
It's often completely off though 😁.
