05-01-2018 01:20 PM
Greetings,
Based on several posts I've found in the forums, I've cobbled together some simple code to <hopefully> allow our calibration PCs to auto-detect the baud rate of the instrument that gets connected (the COM port will always be known and remain constant). It's simply a for-loop that cycles through a list of baud values, and during each iteration the instrument gets pinged for a valid response. Once validated, the serial settings can be configured and the calibrations can be performed automatically.
If I use the "Simple Serial" example (pinging at the known baud rate), I get the expected valid response. If I use my new code that cycles through the baud list, I get mostly no response, except for the occasional gibberish that happens when the baud rate doesn't match the instrument... but I never get a "valid" response when the code executes at the known baud rate of my test instrument (test inst set to 38400, all other inst serial params match the default VISA config serial port settings).
A snippet is attached, along with an example of the gibberish with a baud mismatch. I've been experimenting with flushing and/or clearing the buffer, and time delays, but I can't quite fix the problem. Depending on the config, I may get a framing error, or a timeout. The attached snippet doesn't contain the validity test, it just shows the first character received (if any).
Any advice is greatly appreciated!
05-01-2018 01:47 PM
The Tunnel Mode for the For Loop is set to "Last Value". You are only seeing the results of 57600 baud rate case. Since the correct baud is 38400, I would expect that the last value to be gibberish.
Try changing the tunnel mode to "Indexing". Then you will be able to see all the results from all the cases.
Or the alternative is to add a "Conditional Terminal" and exit the For Loop when you receive a valid response.
05-01-2018 02:05 PM
I just noticed one other thing. The Simple Serial.vi sends the command with a "\n" Line Feed terminator and you get a valid response. In your FIND COM.vi you use a "\r" terminator.
Try changing the termination character to \n. BTW You don't need to use Concatenate Strings. Just type the \n at the end of the command.
05-01-2018 03:04 PM
@jamiva...
Thanks for the replies, let me provide additional info...
a. The termination char for my data set is \r. I had changed the Simple Serial default to \r but did not mention that in the OP.
b. The indicator located above the VISA Close updates each iteration, and I've also monitored using probes, so I can confirm that no "valid" response is being received, even in the correct baud iteration. The gibberish is sometimes seen during other iterations depending on timing delays and other mods.
c. The snippet did not include the existing validation test (with conditional exit). I removed it until I can get a consistent valid inst response.
d. The concatenate is temporary. I'm experimenting with different inst commands to see which is the most reliable across the series, and it was easier to split the command and term char until I find the combination that works.
e. LV2015, Windows 7
f. I also ran across a post that contained in big bold letters "REMOVE BYTES AT PORT!!!!!!" (among other suggestions :D). I forget who the author was, but even following his detailed thread I'm still having problems.
I have a working knowledge of serial comms, but not much detail on how LV/VISA handles the nuts and bolts of port configs, especially when cycling through different baud settings. When an invalid baud rate is used does it corrupt the port/session and prevent it from responding correctly during the next iteration? Am I not "resetting" the port correctly after the use of an invalid baud? Any other ideas?
Thanks!
05-01-2018 07:03 PM
No, an invalid baud rate would not corrupt other attempts.
To me it looks like you have a parity/data bits issue. Do you know whether you have the data bits, stop bits, and parity set correctly? If you request 8 data bits and no parity, but the device sends 7 data bits and a parity bit, then many of the characters you receive will be gibberish.
Look at the incoming data as hex bytes, set the string indicator to hex format. Compare that to the situation where you know you are getting correct data.
05-02-2018 09:43 AM
Could you show us what your code looks like after the changes you've made? Actual code, not just a screenshot.
05-02-2018 09:58 AM
When your instrument sends a termination character, using "Bytes at port" is usually wrong.
Opening and closing a VISA Session in a loop is ALWAYS wrong. Open it once, set BAUD inside the loop with a property node, You really don't need to close it (VISA Sessions "Close" mostly automagically depending on LabVIEW.ini settings but, close it once outside the loop.
Put the VISA I/O Session wire on a Shift Register!
Show the conditional terminal on the For Loop and exit with expected response=OK
What is the device on the other end? Can you link to the manual for that device? ( have you read that manual?)
05-02-2018 10:19 AM
@JÞB ha scritto:
Put the VISA I/O Session wire on a Shift Register!
Are you sure? I never did it, and got no problem. I always thought the VISA wire was a sort of named reference to the actual software object.
However, I may be wrong.
05-02-2018 10:45 AM
@pincpanter wrote:
@JÞB ha scritto:
Put the VISA I/O Session wire on a Shift Register!
Are you sure? I never did it, and got no problem. I always thought the VISA wire was a sort of named reference to the actual software object.
However, I may be wrong.
Mostly, that is correct!
There is a non-default setting in options to close VISA sessions automatically when the caller stack goes "Idle" (this can be annoying.) And, VISA Sessions magically <Poof> out of existence when callers leave memory - Really annoying sometimes if using a TestStand Sequence where you expect VISA to be persistent through "MAX" or "XMLHell"
Treat them like "Named Queues." Close one ref you close them all to that session. Change One "Property" the named queue private data changes for that instance. And, that leads to the source of your poor experience.
You open a IO session multiple times to the same "Resource" To Wit ASRL:n and under the hood VISA is revising properties and trying to decide if that is still a session who's properties might just be re-usable (and it needs to get them to DISC in XML format!) LabVIEW does a fairly competent job of keeping up with what VISA expects under an NI VISA Passport. Yet, have you ever seen this?
Small Child: "mom, mom...mom.mom....mommy..."
Exasperated Mother: "What?"
Small Child: "I... I...I Don't remember?"
Yeah, do what I said.
05-02-2018 10:50 AM - edited 05-02-2018 10:52 AM
@pincpanter wrote:
@JÞB ha scritto:
Put the VISA I/O Session wire on a Shift Register!
Are you sure? I never did it, and got no problem. I always thought the VISA wire was a sort of named reference to the actual software object.
However, I may be wrong.
I think the issue here is that, if using a FOR loop, there is always the chance that the FOR loop executes ZERO times. When this happens, anything going in the left side does NOT come out the right side unless a shift register is used. In this case, it would be an empty VISA resource.
EDIT: I see Jeff has already answered this. (It doesn't make my observation incorrect, but maybe it doesn't apply here.)