TCP Request Node - Return Options

[J Dudley]

I use a lot of lab devices, such as precision DC power supplies, that are based on the SCPI (Standard Commands for Programmable Instruments) protocol.

It is much faster (more efficient) to send a bunch of queries to one of these devices separated by their designated command end character(s) (often '\n', '\r' or '\r\n') and it will return the query results separated by the designated response end character(s). The way the TCP Request Node is setup there is no way to take advantage of this... but if there was a way to check for a count of the end characters (instead of just a single end character) it would work great.

Is this something that could be considered for a future update to the TCP Request Node?

[Dave C-J]

Interesting thought. Can the node be set into "keep connection open" mode and then do the split in a following node ?

[J Dudley]

Yes, it can certainly be done but a counter built into the TCP Request Node would be a very clean and simple solution.

[Dave C-J]

then you have to configure the counter....

and the split node can already split on a character :-)

However is it the same as this ? https://www.npmjs.com/package/visa32 - may be a complete wrapper for that into a Node-RED node would actually be better (if is is the correct thing...)

[Dave C-J]

Ah... though that is Windows only.... uurgh.

[J Dudley]

I still think the counter would be a handy, simple & clean option... especially if you would like to close the TCP connection after your queries are complete.

I really appreciate the feedback and the thought process on additional approaches though :)

[J Dudley]

That is too bad because NI (National Instruments) offers their VISA SCPI driver for Linux & Mac OS X too.

[Dave C-J]

Ah - may well be worth a try then... 

[Dave C-J]

you could also try the timeout option if you know how quick it will respond... - and then split... that would then close the connection as well.

[J Dudley]

That is what I was doing but if the device hangs for a moment you can end up getting only partial data... the best solution is to be able to verify a response for each query and also to have a secondary timeout to handle connection issues.