03-03-2019 10:03 AM
Hello all,
I'm currently working on a Lab view interface for a Rocket thrust measurement Test stand. We're using an arduino and XBee connection, although for our current tests we've been using a hardwired connection.
The problem is, the serial data input from our test weights is currently being written to graphs at an incredibly delayed rate. As in, I'll take the weight off the sensor and the graph/response will show that fact dozens of seconds later.
We're using VISA in this to receive serial data (the arduino is coded and calibrated to give accurate weight) in the form of pounds vs seconds.
I previously received advice regarding that implied my using of Bytes at Port was part of the problem. My most recent iteration (17, attached) has replaced BaP with Scan from String, but now I am receiving Error 1 at the SfS, saying that 'an input parameter is invalid.' I'm assuming I've not formatted the out/ingoing string correctly, but I'm not sure as to what letters to use for the format box. As said, serially I'm using Arduino via the VISA.
I've attached my older iteration (13) that uses Bytes at Port for comparison.
Are there any other recommended was to decrease the delay? Ideally, we want the graph updated in real time. Also, we're currently unsure as to what unit of measurement the time axis of the graph is using, could you please enlighten me?
Thank you for your help.
Solved! Go to Solution.
03-03-2019 11:46 AM
The problem is that you have a zero wired to the input of VISA Read called "byte count". Guess how many bytes it is going to read? ZERO!
Wire a a constant that is larger than the longest message you expect to receive. I'm sure if you had read all the advice in another thread telling you about Bytes at Port problems, you would have also been told what to wire up to the VISA Read.
03-03-2019 11:53 AM - edited 03-03-2019 11:55 AM
Hi fireball,
is there a reason to request just "0" bytes from VISARead?
What is the received string in your "17..." VI? Did you debug your VI?
And why don't you use AutoCleanup?
There also should be no wait in the loop, your device will set the loop iteration speed by the rate of the messages it sends.
03-03-2019 12:32 PM
It was the zero thing, bit of a stupid oversight on my part. I set a constant of 10000. Then got an error 85 (bad format of scan string) which I solved easily enough. I'm back to having a problem with the graph being delayed though.
When I didn't have any wait in the loop, the data input kept reading extra zeros in between the actual data, giving a really screwy graph. An updated file is attached (19).
I haven't been using auto cleanup yet because I've been moving things around, it's the last thing on my to do list.
more info: The arduino is sending serial data continuously like this: "0.45 lbs", then next line of data. The data is formatted as ASCII serial data. Could there a problem here?
03-03-2019 12:53 PM
Got the vi working just fine. Eliminated the loop delay, while changing the bit rate to 80 - the
input from the arduino is 80 hertz. I'm assuming 80 is the correct number I want then, unless someone can correct me?
My main problem is that the scan string has a bit of a weird bug. I infrequently get error 85 from it, saying that there's a wrong input string format. I've got it set to scan number, which normally makes it run fine. But then I'll randomly get error 85 upon initialising, which I can correct by merely changing the format to scan SI number, then back to scan number - essentially just resetting it.
03-03-2019 12:53 PM - edited 03-03-2019 12:56 PM
double post
03-03-2019 01:09 PM
This reminds me of Cool Hand Luke -- "What we have here is a failure to communicate". [If you don't know about Cool Hand Luke, go find it on Netflix or Amazon].
I'm going to guess that you are having VISA Communication Issues. The suggestion to not use "Bytes at Port", but instead read, say, 1000 characters and process the (far fewer) characters, ending with a Termination Character (default \n), assumes that (a) the sending device is sending a character string terminated by a Termination Character, and (b) the receiving device is receiving at the same Baud Rate as the sending device and is using compatible Serial Port settings (such as N-8-1, no handshake).
Did you test this? To test, open MAX. Plug in your VISA Device. Find it in MAX and open a VISA Port to it. Try to do a VISA Read in MAX and see if you get a meaningful string, or gibberish. If the latter, adjust settings (start with the Baud Rate -- try 9600, 19200, 38400, 57600, and 115200). If you see something that looks "close" (but a few characters are off), try changing the Parity from None to Even to Odd. Or you can just RTFM for your sending Device (Arduino) and see what Serial Port Parameters it uses, and set your PC's VISA Port appropriately.
Let us know if this helps.
Bob Schor
03-03-2019 02:01 PM - edited 03-03-2019 02:02 PM
The VISA-Arduino settings (Baud, Flow, term char, etc) are all set up for each other.
The main problem is that I keep getting random Error 85 now.
My vi will run now with scan string set to either 'scan number' or 'scan SI number'... Sometimes. I've literally brute forced it via just trying it multiple times until it works.
As the next problem, I've been trying to get Write to Measurements File to work, but I keep only getting a dozen lines of random data. I've tried tying the input source to different points with different threads, but there's been no difference.
03-03-2019 03:45 PM
Your write to measurement file is after the loop with a normal tunnel. That means it will only write what data is at the tunnel after the last iteration of the while loop.
@fireball900 wrote:
I've tried tying the input source to different points with different threads, but there's been no difference.
I have no idea what you are trying to say there.
03-03-2019 06:03 PM
@fireball900 wrote:more info: The arduino is sending serial data continuously like this: "0.45 lbs", then next line of data. The data is formatted as ASCII serial data. Could there a problem here?
Mind sharing your Arduino sketch? Mostly just want to confirm you are properly sending your data.