Hi, I am working through Form 1465 (OptoMMP Protocol Guide) to try to get UDP streaming of CAN bus data from a SNAP-PAC-R1 to an external control computer. I don’t want a fixed streaming interval as the Can bus data comes in at different intervals and I’d rather get the data sent as quickly as possible.
I am looking at page 52 and it says “If you are configuring streaming to use only as a reaction to a digital event or an analog alarm condition, set the streaming interval to 0 (send once).”
That scenario sounds like me. I only want to stream another packet in reaction to a new CAN Bus packet being received (packet intervals vary between 40 and 1000ms, depending on the device on the bus). However, I’m not sure what sort of digital event I can set up to react to a new packet being received, or indeed if this is the proper application.
Can someone advise?
Kind Regards
Bart
Hi Bart,
If I needed to do something with UDP and had an R1, I’d rather do it in the strategy rather than try to use digital events, etc., for a variety of reasons. Here are a couple of links re: using UDP in a chart:
http://www.opto22.com/community/showthread.php?t=159
http://www.opto22.com/community/showthread.php?t=673
Can you tell us a bit more about your scenario?
Thanks,
-OptoMary
Hi Mary, thanks for your response. The scenario is that we want to stream CAN bus data to a remote controller computer in as near as real time as possible from a SNAP-PAC-R1. I can get the CAN bus data into the PAC just fine. The CAN bus data arrives asynchronously and at intervals varying from 40ms for some sensors to 160ms for others.
A stop-gap solution is to write to the scratch pad float area and have the remote controller computer poll it, but the streaming idea seems more elegant.
Let me know if you have any more questions.
Thanks, Bart
In that case, there are a couple of other posts you might want to check out.
This one shows how you can have your strategy logic send out exactly the same UDP packet the mem map does (if you want), or one with less overhead junk you don’t need. Also, you can have it send those packets only when needed. Of course, with UDP you don’t know for sure the message got there. And you’d still have to have logic on that remote controller to receive/parse etc. the data in that UDP packet.
Using the scratch pad like you mentioned is the “standard” way to do these types of peer-to-peer transactions.
However, perhaps you’d rather have this CAN bus data sent directly to a particular variable on that remote controller? If so, check out this non-mem-map peer-to-peer option too. That sample includes some subroutines like PushFloat which–given a float on your local PAC (like the one with the CAN data), and the IP address of your remote controller, and the name of the variable in that remote strategy–will beam that value across the network for you. No extra logic required on the receiving end. There’s some fancy OptoMary magic Optoscript involved (under the covers of the subroutine), which might be a bit much for the newbie, but I’d say it’s a lot more elegant than using those old digital events/alarms in the mem map!
Thoughts? Have I completely confused you?
