LabVIEW
sequential serial reads within a loop
@RavensFan said...
"Nothing about what you say is in the file matches how you are building the string. Something doesn't add up."
EXACTLY! 
Unless my skills are worse than I thought, I've wired it how I *want* it to show up in the file. But having said that, it behaves like it's going through the loop one time for the .11 command write/read, then a second time for the .13 command write/read.
I've attached a partial output file so you can see what is being logged. The fields are as follows:
".11 thru !92 = inst output, followed by two -6001 outputs, followed by date & time"
".13 thru !98 = inst output, followed by two -6001 outputs, followed by date & time"
Ideally, the .11 output/.13 output/-6001 outputs/date&time would be on a single line, with single date & time entries on the end.
In one of my previous code iterations, I had an indicator after each write/read node. While running, the indicators were random. Sometimes the .11 data would show up in the "other" indicator and vice versa. Sometimes the .11 and .13 data would alternate in one indicator or the other. Regardless of what construct i use, I can't seem to get all of the info to write (or even display) onto a single line.
Are you using a project to organize this? It almost seems like you're not actually using the VISAReadWrite.vi that you think you are. With Trim Whitespace there, you shouldn't get the extra carriage returns.
Also, your log file includes the text " .11 [timestamp]"..." .13 [timestamp]".... Nowhere in either VI is the text ".11" and ".13" logged to the file, so SOMETHING is putting it in there. See if you can find what is doing that.
Also, like RavensFan said, expand Index Array instead of copying it, and I'd suggest using the function "Write Delimited Spreadsheet" to handle your delimiter work. Build all of your data into a string array and feed that to Write Delimited Spreadsheet with Append set to True, and it'll be a LOT easier to read and debug. You are already opening and closing the file reference each time you use it anyway, so it will clean up your block diagram a lot at zero performance cost.
Ah, that makes sense. Is it putting a carriage return in the data by any chance? If it's got a carriage return in the data but not at either end, that would screw up your formatting. Trim Whitespace will only get the stuff at the ends of the string. Just a thought.
By the way- this is an *excellent* place to break your project into a subVI. Create a subVI that just does the file logging with string inputs. You can then debug your code by writing known strings to the inputs, and if that subVI runs well, then you *know* your logging works. We can't debug your code properly as we don't have instruments we can talk to- but if you just had a subVI that accepted data as inputs that wrote to a file, all of us could run it on our machines to make sure that works.
This way you can separate your data acquisition from your file writing... and you may even be able to use that subVI in another project one day 🙂
@Heyla wrote:
@RavensFan said...
"Nothing about what you say is in the file matches how you are building the string. Something doesn't add up."
EXACTLY!
I've attached a partial output file so you can see what is being logged. The fields are as follows:
".11 thru !92 = inst output, followed by two -6001 outputs, followed by date & time"
".13 thru !98 = inst output, followed by two -6001 outputs, followed by date & time"
I think your data file looks even worse than what you first posted with even more timestamps in there.
You should follow my other advice and look at what is in the concatenated string indicator to see if what is in that string matches what is in the file.
As Bert says, something is putting more data in those commands than you think it is. Look at NI-SPY (or is it now NI I/O trace) to see at the driver level for VISA what the data comms look like.
You're getting buffer overflows on your Read's. Up the number of bytes read from 100 to something higher, then get back to us.
This is starting to look like an issue with the serial data protocol. Unless you're 100% certain that your device ALWAYS responds with EXACTLY 100 bytes of data, you're going to have issues with buffers that'll show up after running it for a while.
I'd recommend using termchars for this application if your device supports them. If not, I'd use a Wait... then a "Bytes at Port" to read ALL of the data in the nodes.
My theory: you're getting multiple responses with newline characters in the *middle* of your buffer reads, throwing newlines into your output.
There are definitely newline characters coming in.
The buffer overruns seem to have already started by the time your capture began. What I see in the capture:
First read:
Ask for 100, get 19. Ends at the linefeed character (ends with CR/LF 0D 0A) as expected since the VISA Configure is set for termination character enabled and for Linefeed. Data is ASCII and I believe is what you were describing in the original post.
Second read:
Ask for 100, get 59. Ends at linefeed character. Is the second .11 request, but has a lot more stuff in it like the timestamp which you didn't mention in the first message.
Third read:
Similar to second with a .11 request, again with timestamp.
Fourth read.
Like first with a .13 response. But has 39 characters in response.
Later reads:
Similar with .;11 responses and .13 responses.
So it seems like there is extra data in there. And I find it odd that you got two .11 responses in a row. And that a .13 response was shorter the first time than the next time. We still don't know if when you get a VISA read, if you are grabbing all the bytes in the buffer, or the message was longer with a LF in the middle of it effectively breaking it into 2 reads, that you don't get until later with the next request then read, continually reading stale data until the buffer overruns.
I think there are a couple things you should do.
1. Your request string is .11\r, a carriage return. It is odd to end a command with a carriage return when the response comes back ending in a line feed (actually CR/LF). Should your write command be .11\n. ??
2. You use a 1000 millisecond wait until next in your loop. You really should use a regular Wait. The wait until next could cause you to miss loop periods if a given iteration takes longer than a second.
3. Perhaps get rid of the wait and let the DAQ timing control your loop speed. Set your DAQ to be continuous samples with a 1 Hz rate acquiring 1 sample. It will control your loop iteration time. Better yet, use real DAQmx functions instead of the DAQ Assistant.
4. Simplify your program to do a single call without a loop. Disable the termination character, do a single write such as .11\r, wait 2 seconds, then do a single read of 1000 bytes. Let the program end. i.e. no while loop. This should give you everything that is being returned. Then repeat the process for the .13\r command.
I don't think you've ever told us what instrument you are talking to. Is it a commercial instrument or something someone programmed on their own. What does the manual say about the communication protocol? So far what you've told us it should be doing just doesn't match what is actually happening.
Step 4 above should help figure out what makes up the full response to a give command. The buffer overrun, the extra .11 responses in a row, all make me think you are getting a longer message with line feeds in the middle and the number of VISA Reads isn't enough to empty the buffer before it eventually overruns.
Oh. And the original problem is more about the extra line feeds showing up in the text file. I still don't see why that is happening. as your Clean text should be stripping them off the end. But in your new VI , you got rid of the indicator after you concatenate everything together. That is what I told you to look at see why there would be extra line breaks in the middle of what is getting written to the file.
Actually, something just occurred to me. You are obviously getting errors for the overrun. Most LabVIEW functions will not execute on an incoming error. So if you get an overrun error on your first VISA Write/Read, the subsequent one won't execute. But then again, neither would the file open or write since they are all connected to the same error line. So I don't know how anything gets written to the file, but it could explain why there are incomplete messages. Put some error indicators on all those error wires.
That means you really need to go and solve the VISA communication problems. If you fix them, then perhaps the file write problems disappear.
