LabVIEW
Convert byte to integer, have troube in type cluster
@feelsomoon wrote:
You seem to have found the problem already but the error is obvious even from just an image (usully images are pretty worthless for debugging since a LabVIEW dagram has more than 2 dimensions, think options and configuration in nodes and controls/constants, and what bit you in this instance the data type of the constant).
The display control is U16 but there is a red dot on the wire from the Unflatten from String, so the datatype of the constant that tells the Unflatten from String what type to try to create is something else, most likely the LabVIEW default I32. Now an I32 needs 4 bytes but you only pass 2 bytes to the Unflatten function. It has every right to complain that the desired data can never safely be created from that bytestream.
As others already mentioned Bytes at Serial Port is wrong, except that I don't agree with the percentage from Gerd, it's not 99.9% wrong but an indefinidesimal fraction from 100% (99.9999999999999999%). The only time I have ever used that in a real program was with a stupid device that simply threw out data every second without any way of telling it anything, there wasn't even an RxD line on that device to give it any commands, nor RTS/CTS or whatever.n And there I didn't use it to find out how many data I had to read but only to see if there was still data in the buffer that had accumulated since the last time I read from the buffer as I did not want a stale data set from several minutes ago but only the latest and greatest. Even that could have been solved with a simple Read in a loop with a very short timeout since the device did send its blobs with a termination character.
Now looking at all the code and samples you posted there still is something not quite right. In one code image (why always only images and not the actual VI too?) you do configure the VISA line to also append the termination character on write (don't do that but append that character yourself explicitly to each string you wire to the VISA Write function), and you supposedly send of "LOOP\s1\n" which with the VISA appended termination character should really give you two dots at the end of the Loop command in the NI-Spy log.
So inconsistent information once more which makes debugging this hard.
Timeout on VISA Read typically means three things:
- wiring errors (the TxD line from the device could be not wired correctly after all) There is a joke that RS-232 really is just the abbreviation for "resolder 2 to 3 and 3 to 2" which are the pin numbers for the RxD and TxD lines on a serial port connector both for 25 pin and 9 pin DSUBs but of course those two connector types have them interchanged too.
- The device did not see a command it recognizes, some devices return something like an error response others just sit there and think: Stupid, I don't know what you are saying and I won't do anything then!
- The device did not see the expected termination character and just sits there and waits indefinitely for such a character to appear before it will care to try to interpret the received command and act on it.
Basically you have reached a point where remote debugging has pretty much lost much of its value and it is you who has the device on your desk who has to do the work.
If what you say about the string display being correctly set to display backslash codes and therfore you really send off a newline rather than a backslash followed by an n, then our possibilities to help you further from a distance are very limited.
I do agree with the others that termination mode should be disabled during waiting for a response to this command, but most other commands for this device simply respond with a normal ASCI sequence with proper termination character, although not very consistent, some responses contain up to three <CR><LF>. From a protocol design point of view this device is a true mess!
@rolfk wrote:
As others already mentioned Bytes at Serial Port is wrong, except that I don't agree with the percentage from Gerd, it's not 99.9% wrong but an indefinidesimal fraction from 100% (99.9999999999999999%). The only time I have ever used that in a real program was with a stupid device that simply threw out data every second without any way of telling it anything, there wasn't even an RxD line on that device to give it any commands, nor RTS/CTS or whatever.n And there I didn't use it to find out how many data I had to read but only to see if there was still data in the buffer that had accumulated since the last time I read from the buffer as I did not want a stale data set from several minutes ago but only the latest and greatest. Even that could have been solved with a simple Read in a loop with a very short timeout since the device did send its blobs with a termination character.
I will go so far as to say that the Bytes At Port should NEVER (absolutely 100% of the time) be wired to the VISA Read (ie NEVER use the Bytes At Port to determine the number of bytes to read). Only valid use of Bytes At Port is to determine if any data has come in and react when it does. There are instruments out there that only send out data when something changes or somebody manually presses a button or some other random event that has nothing to do with the communication bus. I call this "sporadic data". This is the only time I have legitimately uses the Bytes At Port. Even rolfk's example can be done without the Bytes At Port since it has a regularly scheduled output, just a slow one. But with a long enough timeout, the simple VISA Read with the number of bytes set to be larger than a message will ever be will handle it just fine.
In my case I didn't want a long timeout since the loop that communicated with the device also had to do a few other things. Sure I could have created a separate loop just for this device, but that would have required extra infrastructure to communicate with that loop as well and the project in question was not to write a perfectly designed application but to get the data in and do some extra IO control all in as little development effort as possible.
@rolfk wrote:
- There is a joke that RS-232 really is just the abbreviation for "resolder 2 to 3 and 3 to 2" which are the pin ......
Thanks. I had not heard of that one before.
crossrulz wrote:
I will go so far as to say that the Bytes At Port should NEVER (absolutely 100% of the time)
I wouldn't go that far. Like Rolf said, if it is something like a terminal application you are writing where you just want to display the data as it arrives at the port, then you can wire bytes at port to the read so that it will instantly show whatever as arrived at the port at that time. In these cases, I'd be appending the new data to the end of the past data as I updated a large string indicator to show what the scrolling history. I'd stick by 99.9% because that would mean 1 in 1000 applications would be a terminal type. Rare, but occasionally happens. Rolf says 99.99999...% says and he has done it at least once. That means he must have written a million or a billion other serial applications for the 1 Bytes at Port application to give him that percentage. 
@Mark_Yedinak wrote:
What data, if any, was returned when you got the timeout? What is your timeout value set to? Is it large enough for you to be able to receive all of the data? Serial communications are not the fastest in the world and if your timeout for the read is too short you will get a timeout and partial data.
I got no data when I got the timeout. I increased the timeout value to 10000 ms when testing. One successful write and read in the test panel only has a time difference of 3 s when I clicked the read button manually. So I suppose 10000 ms should be long enough?
