06-13-2020 03:43 AM - edited 06-13-2020 03:50 AM
Your device uses a somewhat strange reply format in sending multiline replies but nothing that is inherently difficult to implement.
it seems like the firmware developer has been in the past developing HTTP devices and from that felt that multiline responses are cool! 😀 While I wouldn’t do it like that it’s a valid option. If it is truely HTTP inspired it would append always an extra empty line only consisting of a carriage return and linefeed. If it does, the proper reading routine would loop until it finds fhis empty line and then return the concatenation of all read lines with the line endings removed. Otherwise the protocol better used an (optionally different per command) fixed number of lines in the response.and your read Vi would have a configurable input that specifies the amount of lines to read in a loop. After sending the command you then call this read VI with the number of expected lines for that command.
If neither of these options applies to your instrument, it’s really not a proper instrument at all and the developer should rather have gone doing something else than wasting valuable resources such as metals, plastic and energy for the creation of this device!
The need to use Bytes at Serial Port is ALWAYS wrong!!! In 99.9% of the cases it is about not understanding the protocol and simply throwing something together that might seem to work. The remaining 0.1% are borked devices that should never ever have been developed!
06-15-2020 05:23 AM
@rolfk wrote:
Your device uses a somewhat strange reply format in sending multiline replies but nothing that is inherently difficult to implement.
it seems like the firmware developer has been in the past developing HTTP devices and from that felt that multiline responses are cool! 😀
I deal with command line terminals constantly that do this (Linux or simple microcontrollers). For example, the 'ls' command will return a line for every file in a directory. It is not HTTP inspired.