@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.
@Mickster said:
Some of the stuff that is merely parroted here is laughable.....straight from a Siemens/AB/Beckhoff brochure.
Care to be specific instead of widely throwing abuse at nothing in particular?
"Ladder logic intended to be understood by those accustomed to relay logic"
I served my apprenticeship as a panel builder and was excited when the boss announced that we were "going software" and we received our first Gould Modicon. Only the apprentices would go anywhere near it. The experienced guys ran away. Anyone keen enough to learn how to use a PLC could've just as easily picked-up on a procedural language.
BASIC has always been under attack for its "GOTO"....Ever tried to debug a ladder-logic program?
I have had to tie-in to so many production lines, involving equipment supplied by other vendors and had to wait for them to solve ridiculously simple ladder-logic sequence problems.
We stopped using relay-logic 40years ago but we're still using/teaching this format.
I busted a guy once, it was a big-auto supplier and my CNC machine fed a completely automated line. I was stuck in a motel, on-call 24/7 until the line was deemed reliable enough. Every time that the line stopped, I received a call...Rarely was it my machine that had caused the stoppage. I started to see a pattern to this. They had repurposed some existing equipment that had been rebuilt and re-controlled by in-house maintenance. They had replaced relay logic with PLCs but only one of the many maintenance techs had bothered to learn ladder-logic and became their "computer guy".
I discovered that he had used a combination of timers and counters to intentionally lock-up the sequence and it would always be him to-the-rescue. I became suspicious when I noticed that it was always a quick fix.
And then I have to work with the guy who can't figure-out why his programming license is no-longer valid when it should be. I hit my customer up for the cost of me losing a day, waiting for his guy to get his laptop talking to his PLC and the customer gets upset with me
In any other context of their lives, people wouldn't tolerate this nonsense...but it's only company money.
I don't think you've quoted anything posted by someone else. You're just ranting about a pet peeve.
Ladder Logic offers a degree of rigour that's hard to beat. Even in large multipart machines it still holds up well.
Just don't try to make it do procedural jobs. They should be canned off into either other devices or tucked under the hood. And here the Propeller can excel with spare cogs operating in parallel running other languages. CNC G-code is a good example of a procedural language that fits alongside Ladder.
BTW: I do program in Basic too. In fact I've written far more Basic that Ladder. The packaging machine we're designing is primarily controlled with Basic. The main controller, named Trio MC405, is not a PLC however. Its manufacturer calls it a motion coordinator.
@evanh said:
BTW: I do program in Basic too. In fact I've written far more Basic that Ladder. The packaging machine we're designing is primarily controlled with Basic. The main controller, named Trio MC405, is not a PLC however. Its manufacturer calls it a motion coordinator.
These products are first-rate but if/when they fail, what kind of downtime are we looking at? Bean counters forbid spares on the shelf.
With today's MCUs, it's a couple of bucks to supply 100% redundancy.
Be honest, if you owned the company, would you prefer the cost of a replacement MC405 + downtime cost (the real killer) or would you prefer to have a redundant system, ready to go?
Yeah, it doesn't happen but there's absolutely no reason why not.
@Rayman said:
@"R Baggett" That input scheme sounds easier... Input goes through 10k resistor and then there is a 3V zener to ground before getting to P2, right?
Yep, that is it..
For something that will be pulled down from some unknown input voltage, I do this:
I have looked at the BUD boxes in this system before. I haven't done it, but I am pretty sure I could print a guard to accommodate a terminal like this:
@"R Baggett" said:
I have looked at the BUD boxes in this system before. I haven't done it, but I am pretty sure I could print a guard to accommodate a terminal like this:
which would provide a much higher density. I keep running out of panel space for the bigger BUD boxes, and out of terminal count for the smaller ones.
those are interesting.
I have some single row ones, but found that they don't accept these on the ends on the wire, which make a tidy uniform box and give confidence in secure connection of relatively fine signal wire in screw term connections. https://www.digikey.com/en/products/filter/terminal-block-wire-ferrules/364?s=N4IgTCBcDaIGYFMBOSCuAbBIC6BfIA
but.... the double density ones you show, and for single digital signal use to, for examples, adjacent din rail mounted relay coils. make more sense. worth some thought.
@evanh said:
Mickster, you do seem to wander off on tangents a lot. Your points aren't clear at all.
Yeah I'm aware of that
Which seems at odds with your stated desire of simplicity and openness.
No, it's just that I don't take much time to compose. I usually stop off at the PC when I grab a coffee, take a quick stab on the keyboard then off to put-out a fire, somewhere.
Quite simply, what I'm all about is rejecting these ridiculous beliefs that prevail within the industry. I'm reminded of:
Science: Questions which may never be answered
Religion: Answers which may never be questioned
And the controls industry has become very much like a religion. No-end of "experts" that when faced with a crisis are totally useless due to indoctrination.
Remember the EtherCAT thread? For an engineer of @ManAtWork's caliber, that should've been a couple of hours work...were it any good.
EtherCAT is all the rage but nobody can explain why (marketing). We are constantly reminded of "industrial ruggedness" and now megabuck plant relies on puny RJ45 connectors.
You really couldn't make this stuff up. (yeah off on another tangent )
@refaQtor said:
those are interesting.
I have some single row ones, but found that they don't accept these on the ends on the wire, which make a tidy uniform box and give confidence in secure connection of relatively fine signal wire in screw term connections. https://www.digikey.com/en/products/filter/terminal-block-wire-ferrules/364?s=N4IgTCBcDaIGYFMBOSCuAbBIC6BfIA
but.... the double density ones you show, and for single digital signal use to, for examples, adjacent din rail mounted relay coils. make more sense. worth some thought.
Yes, I like ferrules. Of late though I have been doing stuff that needs ludicrous levels of I/O with no space available.
Those terminals come in larger sizes as well. I haven't investigated the minimum pitch needed for ferrules, but I imagine the non insulated ones when square crimped will probably fit in the 150 mil variant with small enough wire.. Probably not 14 ga. though, which should probably be accommodated. With 14 ga, we are probably back at 200 mils, and I doubt 2 rows will fit in the Budd.
@Mickster said:
Quite simply, what I'm all about is rejecting these ridiculous beliefs that prevail within the industry. I'm reminded of:
Science: Questions which may never be answered
Religion: Answers which may never be questioned
You seem to have a few of your own. Sometimes it actually takes time and effort to solve science. Not everything is easy.
And you've still not quoted anything you were complaining about in this topic.
And the controls industry has become very much like a religion. No-end of "experts" that when faced with a crisis are totally useless due to indoctrination.
Remember the EtherCAT thread? For an engineer of @ManAtWork's caliber, that should've been a couple of hours work...were it any good.
EtherCAT is all the rage but nobody can explain why (marketing). We are constantly reminded of "industrial ruggedness" and now megabuck plant relies on puny RJ45 connectors.
You really couldn't make this stuff up. (yeah off on another tangent )
That's not a specific quote either but is that an example for me to consider? That ManAtWork is some sort of failure generally because it took him more than a couple of hours to do something with EtherCAT. You still need to be more specific though.
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.
"Ladder logic intended to be understood by those accustomed to relay logic"
I served my apprenticeship as a panel builder and was excited when the boss announced that we were "going software" and we received our first Gould Modicon. Only the apprentices would go anywhere near it. The experienced guys ran away. Anyone keen enough to learn how to use a PLC could've just as easily picked-up on a procedural language.
BASIC has always been under attack for its "GOTO"....Ever tried to debug a ladder-logic program?
I have had to tie-in to so many production lines, involving equipment supplied by other vendors and had to wait for them to solve ridiculously simple ladder-logic sequence problems.
We stopped using relay-logic 40years ago but we're still using/teaching this format.
I busted a guy once, it was a big-auto supplier and my CNC machine fed a completely automated line. I was stuck in a motel, on-call 24/7 until the line was deemed reliable enough. Every time that the line stopped, I received a call...Rarely was it my machine that had caused the stoppage. I started to see a pattern to this. They had repurposed some existing equipment that had been rebuilt and re-controlled by in-house maintenance. They had replaced relay logic with PLCs but only one of the many maintenance techs had bothered to learn ladder-logic and became their "computer guy".
I discovered that he had used a combination of timers and counters to intentionally lock-up the sequence and it would always be him to-the-rescue. I became suspicious when I noticed that it was always a quick fix.
And then I have to work with the guy who can't figure-out why his programming license is no-longer valid when it should be. I hit my customer up for the cost of me losing a day, waiting for his guy to get his laptop talking to his PLC and the customer gets upset with me
In any other context of their lives, people wouldn't tolerate this nonsense...but it's only company money.
I don't think you've quoted anything posted by someone else. You're just ranting about a pet peeve.
Ladder Logic offers a degree of rigour that's hard to beat. Even in large multipart machines it still holds up well.
Just don't try to make it do procedural jobs. They should be canned off into either other devices or tucked under the hood. And here the Propeller can excel with spare cogs operating in parallel running other languages. CNC G-code is a good example of a procedural language that fits alongside Ladder.
BTW: I do program in Basic too. In fact I've written far more Basic that Ladder. The packaging machine we're designing is primarily controlled with Basic. The main controller, named Trio MC405, is not a PLC however. Its manufacturer calls it a motion coordinator.
Yeah, I already mentioned TrioBasic in #66
These products are first-rate but if/when they fail, what kind of downtime are we looking at? Bean counters forbid spares on the shelf.
With today's MCUs, it's a couple of bucks to supply 100% redundancy.
Be honest, if you owned the company, would you prefer the cost of a replacement MC405 + downtime cost (the real killer) or would you prefer to have a redundant system, ready to go?
Yeah, it doesn't happen but there's absolutely no reason why not.
Yep, that is it..
For something that will be pulled down from some unknown input voltage, I do this:
I have looked at the BUD boxes in this system before. I haven't done it, but I am pretty sure I could print a guard to accommodate a terminal like this:
https://www.digikey.com/en/products/filter/terminal-blocks/wire-to-board/371?s=N4IgjCBcoKxaBjKAzAhgGwM4FMA0IB7KAbRAGYAmMAFipAF18AHAFyhAGUWAnASwDsA5iAC++MgHZ4IJJDRY8hEuRhgwMABwNmbSJx4DhYkADYAnNNnyc+IpFLU1Ziie0hW7LnyGj8ErdAyKBg2SvbgAAwmZCYUbh56Xoa+IBoWgVYhinakapLU8br63kb4FDBxGcEKtsoQjO5FST7GGhGViNWhOSCOZjDUFg0JxcnGYGRkEZZd2cpkGhpkqoWeBi34NBodQXJZteGOFBTUrsNN66Xg1EszezVhuauJlylbBVX33XXPoxvXGjgn2sc3C9R0axKbxurmB+0e4F+zSuWykcIePWoESiMDg50hY02ZjSdxBB1I03oxiouNJ8J6GgABABBX4AVX4vBYAHlkABZbCoTAAV242BSVBMAU6X1BpDi+L0ABECMKAEbocXUsBmCDo77hKYRRkANXZnJ5-MFIrFKQAtHqZWSERQJFIqfg7R8nfTlDApbcPSA7UCfRj5gwRFGgA
which would provide a much higher density. I keep running out of panel space for the bigger BUD boxes, and out of terminal count for the smaller ones.
Mickster, you do seem to wander off on tangents a lot. Your points aren't clear at all.
those are interesting.
I have some single row ones, but found that they don't accept these on the ends on the wire, which make a tidy uniform box and give confidence in secure connection of relatively fine signal wire in screw term connections.
https://www.digikey.com/en/products/filter/terminal-block-wire-ferrules/364?s=N4IgTCBcDaIGYFMBOSCuAbBIC6BfIA
but.... the double density ones you show, and for single digital signal use to, for examples, adjacent din rail mounted relay coils. make more sense. worth some thought.
Which seems at odds with your stated desire of simplicity and openness.
No, it's just that I don't take much time to compose. I usually stop off at the PC when I grab a coffee, take a quick stab on the keyboard then off to put-out a fire, somewhere.
Quite simply, what I'm all about is rejecting these ridiculous beliefs that prevail within the industry. I'm reminded of:
Science: Questions which may never be answered
Religion: Answers which may never be questioned
And the controls industry has become very much like a religion. No-end of "experts" that when faced with a crisis are totally useless due to indoctrination.
Remember the EtherCAT thread? For an engineer of @ManAtWork's caliber, that should've been a couple of hours work...were it any good.
EtherCAT is all the rage but nobody can explain why (marketing). We are constantly reminded of "industrial ruggedness" and now megabuck plant relies on puny RJ45 connectors.
You really couldn't make this stuff up. (yeah off on another tangent
)
Yes, I like ferrules. Of late though I have been doing stuff that needs ludicrous levels of I/O with no space available.
Those terminals come in larger sizes as well. I haven't investigated the minimum pitch needed for ferrules, but I imagine the non insulated ones when square crimped will probably fit in the 150 mil variant with small enough wire.. Probably not 14 ga. though, which should probably be accommodated. With 14 ga, we are probably back at 200 mils, and I doubt 2 rows will fit in the Budd.
You seem to have a few of your own. Sometimes it actually takes time and effort to solve science. Not everything is easy.
And you've still not quoted anything you were complaining about in this topic.
That's not a specific quote either but is that an example for me to consider? That ManAtWork is some sort of failure generally because it took him more than a couple of hours to do something with EtherCAT. You still need to be more specific though.