I placed an initial version of OmmpNET on GitHub.
Check the ReadMe.pdf file and the OmmpNET.py file.
Look in OmmpNET.py for the aa variable and change it from my default (‘192.168.10.225’,2001) to match your hardware.
On load, it creates the instance om. So once you have aa set appropriately, try running om.power_up_clear(aa).
In continuing with the OmmpNET.py code, while investigating the Email functionality, I have run into an issue setting and clearing scratch pad bits. It appears that my clr_scratch_pad_bits function is actually setting bits. The packet format is correctly formulated as far as I can tell. I used ioManager to clear the bits, then in my app I read them as 0, but clr_scratch_pad_bits is setting them. ioManager shows that this has happened as well. Any ideas would be welcome here.
Here’s a dump of some messages:
om.get_scratch_pad_bits(aa)
ReadBlockRequest(tl=4, tcode=80, dofs_hi=65535, dofs_lo=4040687616, length=8)
ReadBlockRequest b’000004500000fffff0d8000000080000’
ReadBlockResponse b’000004700000000000000000000803e10000000000000000’
(4, 112, 0, 8, 0)
ReadBlockResponse(tl=1, tcode=7, rcode=0, length=8, value=(0,))
RspFmt(rcode=0, data=(0,))
om.clr_scratch_pad_bits(aa,15)
WriteBlockRequest(tl=8, tcode=16, dofs_hi=65535, dofs_lo=4040688648, length=8, value=15)
(8, 16, 65535, 4040688648, 8, 15)
WriteBlockRequest b’000008100000fffff0d8040800080000000000000000000f’
WriteResponse b’000008200000000000000000’
RspFmt(rcode=0, data=‘No Error’)
om.get_scratch_pad_bits(aa)
ReadBlockRequest(tl=12, tcode=80, dofs_hi=65535, dofs_lo=4040687616, length=8)
ReadBlockRequest b’00000c500000fffff0d8000000080000’
ReadBlockResponse b’00000c700000000000000000000803e1000000000000000f’
(12, 112, 0, 8, 15)
ReadBlockResponse(tl=3, tcode=7, rcode=0, length=8, value=(15,))
RspFmt(rcode=0, data=(15,))
Monitoring ioManager scratchpad bit commands in a network packet analyzer shows something interesting ioManager writes both set and clear masks in the same packet. I’ll have to try this to see if it is an undocumented requirement.
ioManager set bits
00:00:0c:10:00:00:ff:ff:f0:d8:04:00:00:10:00:00:
00:00:00:00:00:00:00:0f:
00:00:00:00:00:00:00:00
ioManager clr bits
00:00:0c:10:00:00:ff:ff:f0:d8:04:00:00:10:00:00:
00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:0f
It turns out that it must be an undocumented requirement, because if I do it it works. Changed the pack format strings so length would be 16 bytes, and make both writes start at 0xf0d80400.
('Scratch Pad bit On mask',CmdFmt(prng(0xF0D80400),16,'M','Q8x')),
('Scratch Pad bit Off mask',CmdFmt(prng(0xF0D80400),16,'M','8xQ')),
// (‘Scratch Pad bit On mask’,CmdFmt(prng(0xF0D80400),8,‘M’,‘Q’)),
// (‘Scratch Pad bit Off mask’,CmdFmt(prng(0xF0D80408),8,‘M’,‘Q’)),
om.set_scratch_pad_bits(aa,15)
WriteBlockRequest(tl=8, tcode=16, dofs_hi=65535, dofs_lo=4040688640, length=16, value=15)
(8, 16, 65535, 4040688640, 16, 15)
WriteBlockRequest b’000008100000fffff0d8040000100000000000000000000f0000000000000000’
WriteResponse b’000008200000000000000000’
RspFmt(rcode=0, data=‘No Error’)
om.get_scratch_pad_bits(aa)
ReadBlockRequest(tl=12, tcode=80, dofs_hi=65535, dofs_lo=4040687616, length=8)
ReadBlockRequest b’00000c500000fffff0d8000000080000’
ReadBlockResponse b’00000c70000000000000000000080000000000000000000f’
(12, 112, 0, 8, 15)
ReadBlockResponse(tl=3, tcode=7, rcode=0, length=8, value=(15,))
RspFmt(rcode=0, data=(15,))
om.clr_scratch_pad_bits(aa,15)
WriteBlockRequest(tl=16, tcode=16, dofs_hi=65535, dofs_lo=4040688640, length=16, value=15)
(16, 16, 65535, 4040688640, 16, 15)
WriteBlockRequest b’000010100000fffff0d80400001000000000000000000000000000000000000f’
WriteResponse b’000010200000000000000000’
RspFmt(rcode=0, data=‘No Error’)
om.get_scratch_pad_bits(aa)
ReadBlockRequest(tl=20, tcode=80, dofs_hi=65535, dofs_lo=4040687616, length=8)
ReadBlockRequest b’000014500000fffff0d8000000080000’
ReadBlockResponse b’000014700000000000000000000800000000000000000000’
(20, 112, 0, 8, 0)
ReadBlockResponse(tl=5, tcode=7, rcode=0, length=8, value=(0,))
RspFmt(rcode=0, data=(0,))
Yeah, looks like either a firmware bug that ioManager works around, or a documentation bug. I wonder if other OptoMMP set/clear bitmasks work this way (scanner flags, digital bank on/off mask and counters mask, event reaction masks…). If they do, then I would think the docs need updated, if not, then I would think it is a very old firmware bug.
I have updated GitHub with some OmmpNET project changes. There is now an OmmpTST.py and an OmmpUTL.py file. See the OmmpNET.pdf file which replaced the ReadMe.pdf file.
In particular logging to the console is now available. Launch OmmpTST.py andt ype utl.start_logging() at the terminal. Then run om.power_up_clear(aa) to see the logging info available.