Asynchronous communication


#1

Our current implementation uses the OPTO22 provided .dll for our control software (Running in Windows) communication with our SNAP-PAC2S2 and indirectly, the EB2’s.

However, when a process requires an extended period of time to accomplish, such as pumping the system to high vacuum, we use a “Trap” to initiate communication from the S2. (Otherwise the Windows software would have to be polling for 90 seconds.) Software folks hate using a trap for a non error event.

Is there an OPTO22 provided method for the SNAP-PAC-S2 to initiate communications with the Windows based software or is polling the only option?


#2

When you say “trap,” you’re talking about an SNMP trap?

Because… that’s just a very specific kind of UDP packet. You could do something similar but not a trap. E.g. have the -S2 send out (via a comm handle) information to “push” data to your Windows PC (which would be listening on a particular port that the S2 sends this data to).

We have a few customers who use UDP packets to push data from a PAC to something else vs. having the something else poll the PAC.


#3

Yes, we are using SNMP Traps to pass information because of the long times between the initiation of a task and it’s completion. Some software folks object to using a trap as a routine communication technique, since its original function is to transmit errors or unplanned unusual activity, although the definition within SNMP is “a trap is a type of ‘Protocol data unit’ used to report an alert or other asynchronous event about a managed subsystem.”.

We are reviewing options, but were hoping there was a canned protocol you had already implemented.

Thanks again…


#4

SNMP is one of the canned protocols we’ve already implemented (and sounds like one who’s packets you already know how to parse). We have others, but the whole “already done” and “you know how to parse” pieces are pretty handy.

Did you convince the others that “trap” can be used for whatever works for you?


#5

It turns out, on further digging, that the issue is the use of UDP rather than TCP.

The real issue is lack of a closed transaction. Traps have been missed.

We need to move to a protocol with acknowledge and error checking.

Rick