@Rayman said:
@refaQtor Liking that idea... The P2 Stamp in PLCC holder is 1.443" square. So can just fit on board B.
lucky, because you had to be pretty clever to fit the P2 Edge with connector. Alternately, you have to be pretty clever to fit a useful amount of I/O out the 9-terminal width bay. but the 9-t bay would fit conveniently 2 of the 2x6 expansion headers on either side, and (I forget, does the P2 Stamp have extra PSRAM?) use the first 4 expansion headers for I/O and the last two for the HMI/console board on top. This would mimic the I/O of the "mini P2 Edge break out board" with a 32MB Edge plugged in. THAT might be a tidy package and easy to prototype on bench with common 2x6 header spacing for the I/O and also fit in the PLC box.
I think my first attempts will fit the wider 15-terminal or 2-bay. Increasing density with something like this in the 15-terminal size : https://www.digikey.com/en/products/detail/same-sky-formerly-cui-devices/CRJ036-5-TH/14322828 leaving enough room for 2-terrminal power connection. TI has an economical RS232/422/485 interface/protection chip that'll sit behind each of those.
@refaQtor P2 Stamp has a Hyperram chip on it, so all kinds of memory. Not sure how much use that is here... Maybe with a display would make more sense..
Not seeing how the edge in its socket could fit in either 1 bay or 2 bay, but maybe missing something...
Not sure what to do about I/O. With I2C bus, maybe 1 bay is good enough for many things.
Modbus appears to be another way to expand.
Are you saying you do RS232/422/485 with ethernet ports and cable?
Haven't seen that, but can see makes things easy...
@Rayman said:
@refaQtor P2 Stamp has a Hyperram chip on it, so all kinds of memory. Not sure how much use that is here... Maybe with a display would make more sense..
I don't really know what to do with the extra RAM...if you're just wanting a standard PLC. but, if constraining to the single bay 9-terminal size as standard, the sx6 expansion headers fit in there.
That might just be too small for common standard. probably unwise to give up pins just to fit in that space. I also toyed with maybe different/extra header arrangements. lots of combinations. just glad to settle on these boxes, in one cross-section at least, that'll help all of us.
Not seeing how the edge in its socket could fit in either 1 bay or 2 bay, but maybe missing something...
the horizontal edge connector fits tidy between the two bays., though it covers th ebottom of the board on one bay, so all the downward pins need to be confined to one bay to distribute across two bays below. the upper header to the display board can go beneath the horizontal P2 Edge. (if using that socket)
Not sure what to do about I/O. With I2C bus, maybe 1 bay is good enough for many things.
Modbus appears to be another way to expand.
in the PLC world, Modbus seems to be the common way to externally gang these together. Modbus RS485 goes easily over all manner of connectors. Arduino OPTA uses a tiny hard to manage edge connector behind a little plug on the side to gang together expansion. I think it is FOLLY trying to gang to the OPTA through I2C and becoming entangled in the Arduino world. Probably having one or two RS485 Modbus ports (even with screw terminals) as a default configuration for the P2 PLC will be the most flexible and robust integration with the standard PLC world.
Are you saying you do RS232/422/485 with ethernet ports and cable?
Haven't seen that, but can see makes things easy...
The capable ( not OPTA) PLCs I've used allow you to configure all type of serial ports out of RJ45 and screw terminals and DB9 connectors.
Standard PLC is available elsewhere. I think the P2 PLC system needs to far exceed what is commonly available.
@Rayman said:
Are you saying you do RS232/422/485 with ethernet ports and cable?
and, while I'm putting that multi serial chip behind, it has a disable pin to bring around the raw pins to I/O buffers/protection and make those accessible on 4 data pins of the RJ45 (in PoE arrangement - though no ethernet, obviously. just keeping pwr/grnd pairs usable). Mostly I've been sticking together quick little perrfoboard arrangements with RJ45 connector and any cheap arduino-like board to connect up oddball, complex, or brand new sensor type (as they all come with Ardweeny libs by default) and speak serially back to my P2 with, basically, a "hello world" sensor sample code.
I suspect I'm not the only one with scads of ardweener compatible bits and bobs around that I don't want to do anything clever with. This is a pretty simple way to connect up a bunch of sensors and collect them all with a big batch of 16 (or more) serial connections on the P2.
and, I won't even mention here what I'm doing with Lisp and inference on the P2
so, it would be comercially sensible to be somewhat compatible/integratable with PLC industrial control.
but, I mean to do more with it.
@Rayman said:
@refaQtor P2 Stamp has a Hyperram chip on it, so all kinds of memory. Not sure how much use that is here... Maybe with a display would make more sense..
oh, wait. with the Hyperram... does that eat up some of the I/O like the 32MB Edge does? so, if it does, then the P2 Stamp would go well on the 9-terminal single bay size, as only four of the 2x6 expansion headers (two for either side) are available anyway.
@Mickster said:
Modbus was designed by Modicon and is garbage, today.
It's 2025....
yup, I concur, the Modbus is cryptic and cumbersome and wrong.... but, what's THE 2025 way to stitch disparate components into EXISTING systems in a maintainable way by people, like yourself, who come later.
the heater, and I think analog voltage out (temperature sense, perrhaps) , is so you can develop a little PID controller. I bet you sit that on the table with a little cup of water on it (or really any mass) on those resistors that work like heating elements. it wouldn't go on a DIN rail.
Not sure why 10 V output though. Kind of thinking I/O should default to 24 VDC. But, not really an expert here...
@Mickster said:
Modbus was designed by Modicon and is garbage, today.
It's 2025....
yup, I concur, the Modbus is cryptic and cumbersome and wrong.... but, what's THE 2025 way to stitch disparate components into EXISTING systems in a maintainable way by people, like yourself, who come later.
Well, it's doable but I take dead machinery and replace everything control related with something that's not going to become obsolete in a few years.
Modbus terminal (never used it):
option default integer
option base 1
'ansi colors
bl$=chr$(27)+"[36m"
wh$=chr$(27)+"[37m"
gr$=chr$(27)+"[32m"
rd$=chr$(27)+"[31m"
'help strings
rec$=gr$+"receive "+wh$
snd$=gr$+"send "+wh$
dim er$(4) length 16 = ("illegal function","illegal address","illegal value","slave fail")
'defaults for this modbus slave
const bitrate=19200 'communication speed
ID=45 'default modbus id
'init system
openport 'serial port
helptext 'show helptext on terminal
'repeated send string (old loop)
do
e$=""
flush_rx
parse
pause 50 'just some time for a message to get in
if loc(1) then e$=e$+input$(loc(1),#1) 'get answer
'e$=right$(e$,len(e$)-1) 'if needed strip break character during transmit
print rec$;:prtx e$
decode e$
loop
sub decode a$
local value,numbyte,i
select case asc(mid$(a$,2,1))
case 03 'read
numbyte=asc(mid$(a$,3,1))
for i=4 to 2+numbyte step 2
value=256*ASC(mid$(a$,i,1))+ASC(mid$(a$,i+1,1))
print "value";(i-2)/2;" &h";right$("000"+hex$(value),4);" (decimal)";value
next
case >127 'error
print rd$;er$(asc(mid$(a$,3,1)));wh$
end select
end sub
'this is the command loop, parsing text entered
sub parse
print : print gr$;ID;wh$;" "; : input txt$ : txt$=UCASE$(txt$)
print
if left$(txt$,2)="ID" then ID=val(mid$(txt$,4)) 'robust
if left$(txt$,2)="RR" then modsend mk_rd$(txt$) : print snd$;:prtx tx$
if left$(txt$,2)="WR" then modsend mk_wr$(txt$) : print snd$;:prtx tx$
end sub
'compiles the string for reading 16 bit holding register
function mk_rd$(a$)
local posi=4:hlp$=right$(a$,len(a$)-3) 'strip the function code
'register number and registeer range are 2 byte MSB first
mk_rd$=chr$(ID)+chr$(3) 'ID + the modbus read register function 3
'get register number, and strip from string
reg=val(hlp$):posi=instr(hlp$," "):if posi>1 then hlp$=right$(hlp$,len(hlp$)-posi)
mk_rd$=mk_rd$+chr$(reg\256)+chr$(reg and 255)
'get number of register to read
num=val(hlp$)
mk_rd$=mk_rd$+chr$(num\256)+chr$(num and 255)
end function
'compiles the string for writing a single 16 bit register
function mk_wr$(a$)
local posi=4:hlp$=right$(a$,len(a$)-3) 'strip the function code
'register number and registeer range are 2 byte MSB first
mk_wr$=chr$(ID)+chr$(6) 'ID + the modbus rwrite register function 6
'get register number, and strip from string
reg=val(hlp$):posi=instr(hlp$," "):if posi>1 then hlp$=right$(hlp$,len(hlp$)-posi)
'reg = reg - 1 'register start at 1 .... not used in documentation copeland
mk_wr$=mk_wr$+chr$(reg\256)+chr$(reg and 255)
'get the value to write to the register
num=val(hlp$)
mk_wr$=mk_wr$+chr$(num\256)+chr$(num and 255)
end function
'prints the string send from UART in readable form on console
sub prtx a$
local i
' print
for i=1 to len(a$)
if i=2 then print choice(asc(mid$(a$,i,1))>127,rd$,bl$);
if i=len(a$)-1 then print choice(check(a$),wh$,rd$);
print right$("0"+hex$(asc(mid$(a$,i,1))),2);" ";
next
print wh$
end sub
'sends ID+PDU in string a$, adds CRC16
sub modsend a$
local m$=a$
'calculate string crc and append crc to string
crc_val=math(crc16 m$,len(m$),&h8005,&hffff,0,1 ,1)
crcl=crc_val and 255:m$=m$+chr$(crcl)
crch=crc_val \ 256:m$=m$+chr$(crch)
'calculate DE time
ms_char!=11*1000/bitrate '1 char = 11 bits (start+8+parity+stop)
ms_mess!=len(m$)*ms_char! 'message total time
'send it through the UART with controlled DE pin
pin(gp2)=1 'DE high
print #1,m$;
pause ms_mess!
pin(gp2)=0 'DE low
tx$=m$ 'global string, just for debugging
end sub
'opens the UART port for communication and the direction control DE
sub openport
'open COM1 port with modbus defaults 19200/8bit/even parity/1 stop
setpin gp1, gp0, COM1 'rx,tx,port
setpin gp2,dout : pin(gp2)=0 'DE pin is GP2
'open "COM1:"+str$(bitrate)+",256,have_data,EVEN" as #1 'interrupt driven
open "COM1:"+str$(bitrate)+",EVEN" as #1
end sub
'checks if e received string has matching CRC in it
function check(a$)
local pd$,cr$
local crc_pd,crc_mes
check=0
if len(a$)>3 then
'separate ID/PDU from message
pd$=left$(a$,len(a$)-2)
crc_pd=math(crc16 pd$,len(pd$),&h8005,&hffff,0,1 ,1)
'separate CRC from message
cr$=right$(a$,2)
crc_mes=256*asc(right$(cr$,1))+asc(left$(cr$,1))
'compare CRC's -> when equal, message is okay.
if crc_mes=crc_pd then check=1
end if
end function
'flush the USRT rx buffer
sub flush_rx
local dum$
'print loc(1)
if loc(1) then dum$=input$(loc(1),#1)
end sub
sub helptext
print gr$+"------------<< PICO MODBUS TERMINAL >>--------------"
print "Type commands and values <space> separated. Values "
print "Hexadecimal values must be preceded by '&h'"
print "Commands: RR (read register), ID (change client ID) "
print "WR (write 1 register)
print "Send string and response string are shown in hex"
print "Some response is decoded. Register value is base-1"
print "example: Read Register 77 (1 register) from client 4"
print "type 'ID 4' then type 'RR 77 1'. End each with <enter>"
end sub
Contrast this mess with NMC
The command packets have the following structure:
Header byte (always 0xAA)
Module Address byte (0 - 255)
Command byte
Additional Data bytes (0 - 15 bytes)
Checksum byte (8-bit sum of the Module Address byte through the last additional data byte)
The Header byte is used to signal the beginning of a command packet. When waiting for a new
command, each module will ignore any incoming data until it sees a Header byte.
The Module Address byte is the address of the target module. The address can be an individual
address, or the group address for the module.
The Command byte is broken up into an upper nibble (4 bits) and lower nibble (4 bits). The lower
nibble contains the command value (0 - 15), and the upper nibble contains the number of additional
data bytes required for that command (0 - 15). It is up to the host to insure that the upper nibble
matches the number of additional data bytes actually sent.
The Additional Data bytes contain the specific data which may be required for a particular command.
Many commands have a “control” or “mode” byte in addition to other parameters required for the
command. Some commands require no additional data. It is up to the host to make sure that the
proper number of additional data bytes is sent for a particular command, and that the upper nibble of
the command byte is equal to this number.
I guess it's a Saelig-Kerr thing and is more accurately Network Modular Control
I have traditionally used a central-control approach but some years ago, I had a project where a DCS (distributed control system) made more sense. Time was short and so I decided to take a chance on this product.
No-name product and so I was braced for a challenge but it turned-out to be child's play. Their MCU has a couple of limitations and so I now have my own version, based on the Pico. Prop is huge overkill for a DCS.
Like most technicians, I don't get to spend my days, honing my programming/MCU skills. I might be tackling a hydraulic/pneumatic/mechanical/electrical problem or you might find me on a milling machine or lathe. If I need to make a code change or diagnose a sequencing problem, I need to be looking at something that is as simple and self-explanatory as possible.
Some of the stuff that is merely parroted here is laughable.....straight from a Siemens/AB/Beckhoff brochure. Most end-users are mom & pop shops. In the relay-logic days, they had a schematic and they'd have a local sparky come-in and get their machine up-and-running. Now they have this "computer" that they can't do a darned thing with.
So my goal is to provide something that can be maintained by anyone which is why I have a Basic interpreter with editor built-in to the front-end MCU.
Example and this is absolutely the way it went down: I was sitting at a beach-bar, Jesolo beach, Venice, Italy. It was a Sunday and my phone went off (Zello walkie-talkie app, actually). It was Bluebird, corp (one of the southern states). They make most of the yellow school buses. A machine that had been retrofitted by us was giving trouble. It couldn't get within tolerance and so production was down...no buses.
They had already figured that the problem was due to mechanical backlash that they had no-way of fixing without a new speed reducer. They wanted me to make some changes to allow the machine to run, regardless.
I only had my Galaxy S5 phone but the beach bar had WiFi. Using TeamViewer on that tiny screen, I was able to access the machine's interpreter and make the change.
I charged handsomely for the service but they were delighted. All it cost me was missing a few minutes of the topless volleyball that was happening on the beach.
Comments
@refaQtor Liking that idea... The P2 Stamp in PLCC holder is 1.443" square. So can just fit on board B.
lucky, because you had to be pretty clever to fit the P2 Edge with connector. Alternately, you have to be pretty clever to fit a useful amount of I/O out the 9-terminal width bay. but the 9-t bay would fit conveniently 2 of the 2x6 expansion headers on either side, and (I forget, does the P2 Stamp have extra PSRAM?) use the first 4 expansion headers for I/O and the last two for the HMI/console board on top. This would mimic the I/O of the "mini P2 Edge break out board" with a 32MB Edge plugged in. THAT might be a tidy package and easy to prototype on bench with common 2x6 header spacing for the I/O and also fit in the PLC box.
I think my first attempts will fit the wider 15-terminal or 2-bay. Increasing density with something like this in the 15-terminal size : https://www.digikey.com/en/products/detail/same-sky-formerly-cui-devices/CRJ036-5-TH/14322828 leaving enough room for 2-terrminal power connection. TI has an economical RS232/422/485 interface/protection chip that'll sit behind each of those.
@refaQtor P2 Stamp has a Hyperram chip on it, so all kinds of memory. Not sure how much use that is here... Maybe with a display would make more sense..
Not seeing how the edge in its socket could fit in either 1 bay or 2 bay, but maybe missing something...
Not sure what to do about I/O. With I2C bus, maybe 1 bay is good enough for many things.
Modbus appears to be another way to expand.
Are you saying you do RS232/422/485 with ethernet ports and cable?
Haven't seen that, but can see makes things easy...
I don't really know what to do with the extra RAM...if you're just wanting a standard PLC. but, if constraining to the single bay 9-terminal size as standard, the sx6 expansion headers fit in there.
That might just be too small for common standard. probably unwise to give up pins just to fit in that space. I also toyed with maybe different/extra header arrangements. lots of combinations. just glad to settle on these boxes, in one cross-section at least, that'll help all of us.
the horizontal edge connector fits tidy between the two bays., though it covers th ebottom of the board on one bay, so all the downward pins need to be confined to one bay to distribute across two bays below. the upper header to the display board can go beneath the horizontal P2 Edge. (if using that socket)
in the PLC world, Modbus seems to be the common way to externally gang these together. Modbus RS485 goes easily over all manner of connectors. Arduino OPTA uses a tiny hard to manage edge connector behind a little plug on the side to gang together expansion. I think it is FOLLY trying to gang to the OPTA through I2C and becoming entangled in the Arduino world. Probably having one or two RS485 Modbus ports (even with screw terminals) as a default configuration for the P2 PLC will be the most flexible and robust integration with the standard PLC world.
The capable ( not OPTA) PLCs I've used allow you to configure all type of serial ports out of RJ45 and screw terminals and DB9 connectors.
Standard PLC is available elsewhere. I think the P2 PLC system needs to far exceed what is commonly available.
and, while I'm putting that multi serial chip behind, it has a disable pin to bring around the raw pins to I/O buffers/protection and make those accessible on 4 data pins of the RJ45 (in PoE arrangement - though no ethernet, obviously. just keeping pwr/grnd pairs usable). Mostly I've been sticking together quick little perrfoboard arrangements with RJ45 connector and any cheap arduino-like board to connect up oddball, complex, or brand new sensor type (as they all come with Ardweeny libs by default) and speak serially back to my P2 with, basically, a "hello world" sensor sample code.
I suspect I'm not the only one with scads of ardweener compatible bits and bobs around that I don't want to do anything clever with. This is a pretty simple way to connect up a bunch of sensors and collect them all with a big batch of 16 (or more) serial connections on the P2.
and, I won't even mention here what I'm doing with Lisp and inference on the P2
so, it would be comercially sensible to be somewhat compatible/integratable with PLC industrial control.
but, I mean to do more with it.
oh, wait. with the Hyperram... does that eat up some of the I/O like the 32MB Edge does? so, if it does, then the P2 Stamp would go well on the 9-terminal single bay size, as only four of the 2x6 expansion headers (two for either side) are available anyway.
Not gonna gain a darned thing by trying to be compatible with ancient technology.
Modbus was designed by Modicon and is garbage, today.
It's 2025.... People know how to type instructions..... nobody understands relay logic anymore.
Stick a PicoMite on the front end and be done with it....why waste Prop resources.
We already know you dislike this topic Craig. Please contribute in other topics.
yup, I concur, the Modbus is cryptic and cumbersome and wrong.... but, what's THE 2025 way to stitch disparate components into EXISTING systems in a maintainable way by people, like yourself, who come later.
the heater, and I think analog voltage out (temperature sense, perrhaps) , is so you can develop a little PID controller. I bet you sit that on the table with a little cup of water on it (or really any mass) on those resistors that work like heating elements. it wouldn't go on a DIN rail.
just common voltages they'll see in the field
10V is analogue. Either 0..10V or -10..10V. And can be inputs too. 10bit, 12bit and 16bit all exist.
Spindle drive command is 0 - 10v
Torque limiting of servo drives is 0 - 10v
If one desires to have full PID control of an industrial servo drive (my preference), a motor command of +/- 10v is required.
Ok, I’m seeming the value of having the bottom board being customizable
They do sell a blank pcb for these so people can make what they want…
Well, it's doable but I take dead machinery and replace everything control related with something that's not going to become obsolete in a few years.
Modbus terminal (never used it):
option default integer option base 1 'ansi colors bl$=chr$(27)+"[36m" wh$=chr$(27)+"[37m" gr$=chr$(27)+"[32m" rd$=chr$(27)+"[31m" 'help strings rec$=gr$+"receive "+wh$ snd$=gr$+"send "+wh$ dim er$(4) length 16 = ("illegal function","illegal address","illegal value","slave fail") 'defaults for this modbus slave const bitrate=19200 'communication speed ID=45 'default modbus id 'init system openport 'serial port helptext 'show helptext on terminal 'repeated send string (old loop) do e$="" flush_rx parse pause 50 'just some time for a message to get in if loc(1) then e$=e$+input$(loc(1),#1) 'get answer 'e$=right$(e$,len(e$)-1) 'if needed strip break character during transmit print rec$;:prtx e$ decode e$ loop sub decode a$ local value,numbyte,i select case asc(mid$(a$,2,1)) case 03 'read numbyte=asc(mid$(a$,3,1)) for i=4 to 2+numbyte step 2 value=256*ASC(mid$(a$,i,1))+ASC(mid$(a$,i+1,1)) print "value";(i-2)/2;" &h";right$("000"+hex$(value),4);" (decimal)";value next case >127 'error print rd$;er$(asc(mid$(a$,3,1)));wh$ end select end sub 'this is the command loop, parsing text entered sub parse print : print gr$;ID;wh$;" "; : input txt$ : txt$=UCASE$(txt$) print if left$(txt$,2)="ID" then ID=val(mid$(txt$,4)) 'robust if left$(txt$,2)="RR" then modsend mk_rd$(txt$) : print snd$;:prtx tx$ if left$(txt$,2)="WR" then modsend mk_wr$(txt$) : print snd$;:prtx tx$ end sub 'compiles the string for reading 16 bit holding register function mk_rd$(a$) local posi=4:hlp$=right$(a$,len(a$)-3) 'strip the function code 'register number and registeer range are 2 byte MSB first mk_rd$=chr$(ID)+chr$(3) 'ID + the modbus read register function 3 'get register number, and strip from string reg=val(hlp$):posi=instr(hlp$," "):if posi>1 then hlp$=right$(hlp$,len(hlp$)-posi) mk_rd$=mk_rd$+chr$(reg\256)+chr$(reg and 255) 'get number of register to read num=val(hlp$) mk_rd$=mk_rd$+chr$(num\256)+chr$(num and 255) end function 'compiles the string for writing a single 16 bit register function mk_wr$(a$) local posi=4:hlp$=right$(a$,len(a$)-3) 'strip the function code 'register number and registeer range are 2 byte MSB first mk_wr$=chr$(ID)+chr$(6) 'ID + the modbus rwrite register function 6 'get register number, and strip from string reg=val(hlp$):posi=instr(hlp$," "):if posi>1 then hlp$=right$(hlp$,len(hlp$)-posi) 'reg = reg - 1 'register start at 1 .... not used in documentation copeland mk_wr$=mk_wr$+chr$(reg\256)+chr$(reg and 255) 'get the value to write to the register num=val(hlp$) mk_wr$=mk_wr$+chr$(num\256)+chr$(num and 255) end function 'prints the string send from UART in readable form on console sub prtx a$ local i ' print for i=1 to len(a$) if i=2 then print choice(asc(mid$(a$,i,1))>127,rd$,bl$); if i=len(a$)-1 then print choice(check(a$),wh$,rd$); print right$("0"+hex$(asc(mid$(a$,i,1))),2);" "; next print wh$ end sub 'sends ID+PDU in string a$, adds CRC16 sub modsend a$ local m$=a$ 'calculate string crc and append crc to string crc_val=math(crc16 m$,len(m$),&h8005,&hffff,0,1 ,1) crcl=crc_val and 255:m$=m$+chr$(crcl) crch=crc_val \ 256:m$=m$+chr$(crch) 'calculate DE time ms_char!=11*1000/bitrate '1 char = 11 bits (start+8+parity+stop) ms_mess!=len(m$)*ms_char! 'message total time 'send it through the UART with controlled DE pin pin(gp2)=1 'DE high print #1,m$; pause ms_mess! pin(gp2)=0 'DE low tx$=m$ 'global string, just for debugging end sub 'opens the UART port for communication and the direction control DE sub openport 'open COM1 port with modbus defaults 19200/8bit/even parity/1 stop setpin gp1, gp0, COM1 'rx,tx,port setpin gp2,dout : pin(gp2)=0 'DE pin is GP2 'open "COM1:"+str$(bitrate)+",256,have_data,EVEN" as #1 'interrupt driven open "COM1:"+str$(bitrate)+",EVEN" as #1 end sub 'checks if e received string has matching CRC in it function check(a$) local pd$,cr$ local crc_pd,crc_mes check=0 if len(a$)>3 then 'separate ID/PDU from message pd$=left$(a$,len(a$)-2) crc_pd=math(crc16 pd$,len(pd$),&h8005,&hffff,0,1 ,1) 'separate CRC from message cr$=right$(a$,2) crc_mes=256*asc(right$(cr$,1))+asc(left$(cr$,1)) 'compare CRC's -> when equal, message is okay. if crc_mes=crc_pd then check=1 end if end function 'flush the USRT rx buffer sub flush_rx local dum$ 'print loc(1) if loc(1) then dum$=input$(loc(1),#1) end sub sub helptext print gr$+"------------<< PICO MODBUS TERMINAL >>--------------" print "Type commands and values <space> separated. Values " print "Hexadecimal values must be preceded by '&h'" print "Commands: RR (read register), ID (change client ID) " print "WR (write 1 register) print "Send string and response string are shown in hex" print "Some response is decoded. Register value is base-1" print "example: Read Register 77 (1 register) from client 4" print "type 'ID 4' then type 'RR 77 1'. End each with <enter>" end subContrast this mess with NMC
The command packets have the following structure:
Header byte (always 0xAA)
Module Address byte (0 - 255)
Command byte
Additional Data bytes (0 - 15 bytes)
Checksum byte (8-bit sum of the Module Address byte through the last additional data byte)
The Header byte is used to signal the beginning of a command packet. When waiting for a new
command, each module will ignore any incoming data until it sees a Header byte.
The Module Address byte is the address of the target module. The address can be an individual
address, or the group address for the module.
The Command byte is broken up into an upper nibble (4 bits) and lower nibble (4 bits). The lower
nibble contains the command value (0 - 15), and the upper nibble contains the number of additional
data bytes required for that command (0 - 15). It is up to the host to insure that the upper nibble
matches the number of additional data bytes actually sent.
The Additional Data bytes contain the specific data which may be required for a particular command.
Many commands have a “control” or “mode” byte in addition to other parameters required for the
command. Some commands require no additional data. It is up to the host to make sure that the
proper number of additional data bytes is sent for a particular command, and that the upper nibble of
the command byte is equal to this number.
is "NMC" a thing that a technician is likely to encounter in the field in 2025? or is it what you wished all the equipment spoke today?
You've describes some sensible aspects of a protocol, but I can't find anywhere else that uses "NMC" as an industrial protocol.
I suppose no one would mind if you implemented an NMC object, so that propellers could interact with NMC speaking gear.
Otherwise, I'm happy to lament with you the fact that the current industry is saddled with anachronistic protocols.
I guess it's a Saelig-Kerr thing and is more accurately Network Modular Control
I have traditionally used a central-control approach but some years ago, I had a project where a DCS (distributed control system) made more sense. Time was short and so I decided to take a chance on this product.
No-name product and so I was braced for a challenge but it turned-out to be child's play. Their MCU has a couple of limitations and so I now have my own version, based on the Pico. Prop is huge overkill for a DCS.
Like most technicians, I don't get to spend my days, honing my programming/MCU skills. I might be tackling a hydraulic/pneumatic/mechanical/electrical problem or you might find me on a milling machine or lathe. If I need to make a code change or diagnose a sequencing problem, I need to be looking at something that is as simple and self-explanatory as possible.
Some of the stuff that is merely parroted here is laughable.....straight from a Siemens/AB/Beckhoff brochure. Most end-users are mom & pop shops. In the relay-logic days, they had a schematic and they'd have a local sparky come-in and get their machine up-and-running. Now they have this "computer" that they can't do a darned thing with.
So my goal is to provide something that can be maintained by anyone which is why I have a Basic interpreter with editor built-in to the front-end MCU.
Example and this is absolutely the way it went down: I was sitting at a beach-bar, Jesolo beach, Venice, Italy. It was a Sunday and my phone went off (Zello walkie-talkie app, actually). It was Bluebird, corp (one of the southern states). They make most of the yellow school buses. A machine that had been retrofitted by us was giving trouble. It couldn't get within tolerance and so production was down...no buses.
They had already figured that the problem was due to mechanical backlash that they had no-way of fixing without a new speed reducer. They wanted me to make some changes to allow the machine to run, regardless.
I only had my Galaxy S5 phone but the beach bar had WiFi. Using TeamViewer on that tiny screen, I was able to access the machine's interpreter and make the change.
I charged handsomely for the service but they were delighted. All it cost me was missing a few minutes of the topless volleyball that was happening on the beach.
Care to be specific instead of widely throwing abuse at nothing in particular?
interesting stuff. thanks. Now I see where you're coming from. I, too, am intolerant of opaque equipment.