LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

NumatoLab SSR80001 relay

Where can I find LabVIEW drivers for NumatoLab SSR80001 relay?

0 Kudos
Message 1 of 7
(402 Views)

Hi sri,

 


@Sri25 wrote:

Where can I find LabVIEW drivers for NumatoLab SSR80001 relay?


Why don't you look at the Numato website for code examples?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 7
(397 Views)

@Sri25 wrote:

Where can I find LabVIEW drivers for NumatoLab SSR80001 relay?


https://numato.com/help/wp-content/uploads/2025/02/Numato_Lab_USB_Modules_with_LabView.pdf

https://numato.com/wp-content/uploads/2024/10/Numato_Lab_USB_Module_LabView-_Sample_Code.zip

 

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 3 of 7
(390 Views)

I spent some time working with Numato relays using serial communication.  I don't remember all details, but I *do* recall that there were a few quirks that the docs didn't make clear.

 

First of all, their LabVIEW example and docs don't use good practices and aren't going to be reliable to count on.  IIRC, the two main categories of quirks were:

 

1. A pretty uncommon typical termination character, I think maybe it was '>' right after a CR-LF combo?   (Which seems fine when working interactively in a text terminal window because it just looks like a prompt on a new line.  But it's pretty unconventional.).

 

2. Unclear, incomplete, or incorrect docs about the range of possible responses.  Some contained multiple CR-LF's with the more important info in the first of 2 or more "lines" of response.   I *think* (but am not sure I remember correctly) that there might be no response at all to some commands.

 

Overall I remember needing quite a bit of trial and error to work up a set of reliable driver functions.  Unfortunately, not IP I could upload to the instrument driver network.

 

My advice:

- for a first stage, try communicating interactively using a terminal program such as Putty or TeraTerm.   Turn on any logging function that will store comms to file, including timestamps.  Note any differences between actual responses and expected ones.  Try intentionally setting values or parameters to illegal values, see what response you get.  Try to notice which commands give back responses pretty much instantly and which only respond after some perceptible delay.

 

- if the log file timestamps help to show comm flow and timing both ways (i.e., both send and receive message content and times), make note of commands that seem to take a long time to produce responses.  There's a good chance that you wouldn't want to send your Numato relay device another command for at least that much time. It may be ignored, cause an error message, or lead to some other unexpected behavior.

 

I'm not going to be able to offer further detailed help, just the general advice to approach this systematically and carefully.  In Numato's defense, I *will* say that they ended up behaving quite reliably after I worked out the communication kinks.

 

 

-Kevin P

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 7
(320 Views)

@Kevin_Price wrote:

 

1. A pretty uncommon typical termination character, I think maybe it was '>' right after a CR-LF combo?   (Which seems fine when working interactively in a text terminal window because it just looks like a prompt on a new line.  But it's pretty unconventional.).

 


It's actually slightly weirder than that. They end each response line with LF-CR. 😵

 

This is the actual regex I've used for validating the relay read response is "relay read [0-3]\n\r(on|off)\n\r>".

 

So for that command the response is:

  1. Echo the command.
  2. LF-CR
  3. status (on or off)
  4. LF-CR
  5. >

The line endings are just weird, but the rest is a very odd decision to structure the protocol in such a way that it primarily makes sense when using it with an interactive terminal.

0 Kudos
Message 5 of 7
(299 Views)

Yeah, my memory's definitely fuzzy, but I think I opted to declare '>' as the line termination character for the sake of simpler LabVIEW VISA config.  Then the VISA operations didn't need to know how many LF-CR "lines" to expect in the response.  As I recall that let the lower-level raw comms stay simpler and deferred most of the complexity to the command-specific parsing.

 

Not the only way to do it, but I don't recall thinking it was a big mistake either.

 

Were there also a few commands that produced no response message at all?  Maybe not, I might be thinking of a different device I worked on around the same time that also had a kind of oddball serial protocol.  One of them had a quirk that led me to make API functions that would confirm every "write" with a followup confirmation "read".

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 7
(289 Views)

It might have been them if you were trying to read back the relay state after writing it.

 

IIRC, the only response to the "relay on x" and "relay off x" commands is to echo back the command, and I think I remember it doing that even for invalid commands with no real error indication.

0 Kudos
Message 7 of 7
(267 Views)