That's true. all the established industrial stuff is pretty salty. My use case would be WAGO 750-362 and the whole family of 750 series modules that can be attached to it. If it would be helpful, I could send you one and a couple of I/O modules. It's implementation of Modbus TCP is, I am told as close as compatible with with the 'standard' as it gets without saying 'Modicon' on the front.. PM shipping address if you want it.
I would also point out that Codesys IDE is free and comes with a soft controller for Windows and Linux (Even Raspi) that will run unlicensed for 1 hour or so between restarts. It supports Modbus TCP as master, and I think slave as well.
Sadly, the IDE is Windows only.
@Rayman said:
In the future, would like to connect this P2 powered "PLC" for this subsystem to an actual Siemens giant PLC that is going to control everything.
Plan is to connect using ethernet driven on P2 side by a Wiznet module.
No idea if that is going to work though...
Guess need to research that...
With Siemens S7-300/400/1200/1500 series you can do nearly everything. Beside profinet you can also use raw TCP/UDP connections that you setup in the network config to pre-allocate resources or build on the fly during the program execution.
In worst case you may need a CP (Communication Processor card) that means that you will need to add its communication FBs/FCs to your S7 program while the CPUs supporting Ethernet have them already in the OS in form of SFCs/SFBs.
Some CPs supports also FTP server which means you can decide what DBs are available through it and you can transfer its content in both directions with any FTP client.
I've communicated already with nearly everything from ESP32/Tibbo modules to various T&M instrumentation (PSU, SA, DAQ, MSO, ...) using SCPI commands.
With mine CPU417-4 + CP443-1Adv I even controlled (through LAN) a Denon AVR4311 and Samsung UE55ES8000Q smarttv as proof of concept.
So no issues at all, it will work for sure.
And ... the CATegory on LAN cables basically indicates the bandwidth while for shielding grade you need to look at its type ( [S|F]/[S|F|U]TP) as AjL have already correctly explained
@Rayman said:
@"R Baggett" Know of an inexpensive device that would be a good test as a Modbus TCP slave?
Probably no such thing as in inexpensive Modbus TCP master device, right?
Have a look at Tibbo EM2001 boards (eventually with its WA2000C add-on for WiFi and BLE). Very Easy to program. I've never used them with Modbus, but IIRC they have also Modbus TCP gateway/master/slave examples. When I need something done quickly I many times use the EM2001 or WM2000
The Codesys one looks fancy, but they don't seem to allow us USA people to download it...
They are a little funny about it, but it can be DLed after making an account. I think your Modbus tester is a better way to go. Codesys is non-trivial to learn and set up.
From what I'm seeing, the protocol is very simple but the C code found so far is very obfuscated for such a thing. Guess it's so can be used on any device (except P2, of course). Also, meant to be interrupt driven.
Might just implement this in simple spin2 with a dedicated cog and no interrupts.
This seems like an important enough thing to deserve its own cog...
I also have a bunch of that Tibbo product. It would be cool to have a compatible motherboard with a P2. Instant modular P2 PLC right there and professionally packaged.
in fact, I'd used larger fancy (with nice frame that mounts on large industrial enclosure) Nextion displays for Human Machine Interface (HMI) on jobs where I saw others used as well - well.. more of a science lab control system. those displays seem to be bespoke for the purpose of the machine you're creating for the customer, not a generic fiddle with the PLC type of thing.
This is a question that I have asked repeatedly but have never received a response; arguably, the most powerful and ubiquitous HMI is in your pocket.
By far, the #1 failure is the HMI because it is subject to physical abuse.
If your display fails, production grinds to a halt. Why not incorporate a Bluetooth link and talk to the device via any mobile device?
More than 10 years in a grueling environment. Covered in grime and metal shavings. Responds like it was new.
If it should fail, the customer has the same app on his phone until he procures a new Android tablet. It's only a Samsung Galaxy.
The next machine over has a Siemens "industrial HMI". Many of the buttons are dead and the joystick mouse emulator is dead and so (what you'll see on every plant floor) a standard PC keyboard and mouse have been plugged in the back so they can at least use it.
It's nuts. I've been using Android tablets since 2012 and they just run and run.
I used to think that ubiquitous bluetooth touchpad was a brilliant solution and built and bought with that in mind. I don't anymore. (looking at a pile of, essentially, bricked Android tablets/phones with lost passwords or no google account) It seemed cool back in the day to "sideload" stuff, but too many hurdles now, I simply won't tolerate, any longer, the shiifting sands of some unrelated platform gatekeeping my delivery.
Never been a problem. Factory reset is always possible but if that wasn't happening, who cares?
You can always find another. Pair the Bluetooth and you're back in business.
For the particular application being worked on now, the display is just meant to be a simple status display. It is behind a piece of clear plastic, so not easily touched.
And, it is normally encased in a big metal box, so not really for HMI use...
Do want to add an HMI though, if can. The Nextion is nice because only need 2 pins to implement. Thinking about making a box for a Nextion display with RJ45 input, so can use RJ45 feedthrough on main box to connect to it.
But, that might be overkill because already have Omron lighted pushbutton control, USB serial control, and soon network control.
On the other hand, overkill is fine with me
Well pardon the arrogance but I'm all about Occam's Razor.
I see absolutely no need for bespoke user interfaces.
P2 resources are precious
Users are accustomed to phone quality GUIs
There was a cool concept "Simblee" where you had a host app and all that you needed to do was be in close proximity to the device of interest and the appropriate GUI would appear on your device.
Sadly, it faded away.
Sorry to keep harping on about this but you build a PLC. You believe it's going to be deployed where someone can actually see it?
No, machine builders put control panels wherever it suits them.
It's like my DIN rail argument; those who design and implement this stuff are the ones who never end up as the sucker who actually has to work on this stuff, on a ladder, flashlight between your teeth.
We can all design cute stuff but go try working on the installation.
I've recently implemented a MODBUS master for the P1. Because I have very little resources left in my P1 CNC boards the implementation is somehow odd. A small ASM procedure scans a buffer and sends commands to slaves, waits for the responses and writes them to the buffer. Unfortunatelly, it's not very useful to anyone else. But it shows that the basic task is relatively simple.
Forget the "official" documentation. It is overcomplicated because they need to address every application and all possible cases. Usually, only supporting function codes 03 (read multiple registers) and 10 (write multiple registers) is all you need. You can find documentation abou the MODBUS protocol in manuals of VFDs and servo controllers that are much easier to understand. I like the Yaskawa GA500 technical manual, for example. It explains everything, even the CRC algorithm.
I'll soon implement a MODBUS slave for the P2. It will control the power electronics for a medical device. The GUI (with the MODBUS master) will be some sort of tablet PC.
Comments
@"R Baggett" Know of an inexpensive device that would be a good test as a Modbus TCP slave?
Probably no such thing as in inexpensive Modbus TCP master device, right?
That's true. all the established industrial stuff is pretty salty. My use case would be WAGO 750-362 and the whole family of 750 series modules that can be attached to it. If it would be helpful, I could send you one and a couple of I/O modules. It's implementation of Modbus TCP is, I am told as close as compatible with with the 'standard' as it gets without saying 'Modicon' on the front.. PM shipping address if you want it.
I would also point out that Codesys IDE is free and comes with a soft controller for Windows and Linux (Even Raspi) that will run unlicensed for 1 hour or so between restarts. It supports Modbus TCP as master, and I think slave as well.
Sadly, the IDE is Windows only.
With Siemens S7-300/400/1200/1500 series you can do nearly everything. Beside profinet you can also use raw TCP/UDP connections that you setup in the network config to pre-allocate resources or build on the fly during the program execution.
In worst case you may need a CP (Communication Processor card) that means that you will need to add its communication FBs/FCs to your S7 program while the CPUs supporting Ethernet have them already in the OS in form of SFCs/SFBs.
Some CPs supports also FTP server which means you can decide what DBs are available through it and you can transfer its content in both directions with any FTP client.
I've communicated already with nearly everything from ESP32/Tibbo modules to various T&M instrumentation (PSU, SA, DAQ, MSO, ...) using SCPI commands.
With mine CPU417-4 + CP443-1Adv I even controlled (through LAN) a Denon AVR4311 and Samsung UE55ES8000Q smarttv as proof of concept.
So no issues at all, it will work for sure.
And ... the CATegory on LAN cables basically indicates the bandwidth while for shielding grade you need to look at its type ( [S|F]/[S|F|U]TP) as AjL have already correctly explained
Have a look at Tibbo EM2001 boards (eventually with its WA2000C add-on for WiFi and BLE). Very Easy to program. I've never used them with Modbus, but IIRC they have also Modbus TCP gateway/master/slave examples. When I need something done quickly I many times use the EM2001 or WM2000
@dMajo Thanks! Think the S7 is what they are looking at. Good to know there are many options.
Still thinking Modbus TCP is way to go, and looks fairly simple to implement with Wiznet.
Found a Modbus slave code that just got to compile with FlexProp:
https://github.com/cwalter-at/freemodbus
Also, found this modbus tester for PC side here:
https://www.modbustester.com/#download
So, thinking can make this happen...
Thats a good find Ray
We traditionally use that 'cas modbus scanner' but I think what you found is better
@Tubular Ok, downloaded that one here: https://store.chipkin.com/products/tools/cas-modbus-scanner
The Codesys one looks fancy, but they don't seem to allow us USA people to download it...
They are a little funny about it, but it can be DLed after making an account. I think your Modbus tester is a better way to go. Codesys is non-trivial to learn and set up.
So, found a document on Modbus RTU (and others) here:
https://modbus.org/docs/PI_MBUS_300.pdf
From what I'm seeing, the protocol is very simple but the C code found so far is very obfuscated for such a thing. Guess it's so can be used on any device (except P2, of course). Also, meant to be interrupt driven.
Might just implement this in simple spin2 with a dedicated cog and no interrupts.
This seems like an important enough thing to deserve its own cog...
Guess we'll see how this pans out...
I also have a bunch of that Tibbo product. It would be cool to have a compatible motherboard with a P2. Instant modular P2 PLC right there and professionally packaged.
Thinking a PLC thing should have a display. But, might be the only one who thinks so...
Still, maybe this is what multiple cores allow one to have...
depending on the orientation and resulting top face of the device, I noodle around with these:
narrow slot size https://www.amazon.com/dp/B08CDN5PSJ?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_5
wider top face https://www.amazon.com/dp/B0CKRJ81B5?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_1
and the equally wide top face for these easy to interface with 2-wire serial
https://www.amazon.com/dp/B0BKPPHYSF?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_4
easy Spin libs for all on obex
in fact, I'd used larger fancy (with nice frame that mounts on large industrial enclosure) Nextion displays for Human Machine Interface (HMI) on jobs where I saw others used as well - well.. more of a science lab control system. those displays seem to be bespoke for the purpose of the machine you're creating for the customer, not a generic fiddle with the PLC type of thing.
This is a question that I have asked repeatedly but have never received a response; arguably, the most powerful and ubiquitous HMI is in your pocket.
By far, the #1 failure is the HMI because it is subject to physical abuse.
If your display fails, production grinds to a halt. Why not incorporate a Bluetooth link and talk to the device via any mobile device?
More than 10 years in a grueling environment. Covered in grime and metal shavings. Responds like it was new.
If it should fail, the customer has the same app on his phone until he procures a new Android tablet. It's only a Samsung Galaxy.
The next machine over has a Siemens "industrial HMI". Many of the buttons are dead and the joystick mouse emulator is dead and so (what you'll see on every plant floor) a standard PC keyboard and mouse have been plugged in the back so they can at least use it.
It's nuts. I've been using Android tablets since 2012 and they just run and run.
not in my pocket.
I used to think that ubiquitous bluetooth touchpad was a brilliant solution and built and bought with that in mind. I don't anymore. (looking at a pile of, essentially, bricked Android tablets/phones with lost passwords or no google account) It seemed cool back in the day to "sideload" stuff, but too many hurdles now, I simply won't tolerate, any longer, the shiifting sands of some unrelated platform gatekeeping my delivery.
Scenario:
A 24/7 production line goes down at 1am Sunday.
I am up and running within minutes. Nobody keeps spares.
How much time would you need to get a new Nextion display and install it.
Engineers tend to ignore these catastrophic events....it's someone else's problem.
Bricked Android device?
Never been a problem. Factory reset is always possible but if that wasn't happening, who cares?
You can always find another. Pair the Bluetooth and you're back in business.
For the particular application being worked on now, the display is just meant to be a simple status display. It is behind a piece of clear plastic, so not easily touched.
And, it is normally encased in a big metal box, so not really for HMI use...
Do want to add an HMI though, if can. The Nextion is nice because only need 2 pins to implement. Thinking about making a box for a Nextion display with RJ45 input, so can use RJ45 feedthrough on main box to connect to it.
But, that might be overkill because already have Omron lighted pushbutton control, USB serial control, and soon network control.
On the other hand, overkill is fine with me
Well pardon the arrogance but I'm all about Occam's Razor.
I see absolutely no need for bespoke user interfaces.
P2 resources are precious
Users are accustomed to phone quality GUIs
There was a cool concept "Simblee" where you had a host app and all that you needed to do was be in close proximity to the device of interest and the appropriate GUI would appear on your device.
Sadly, it faded away.
Sorry to keep harping on about this but you build a PLC. You believe it's going to be deployed where someone can actually see it?
No, machine builders put control panels wherever it suits them.
It's like my DIN rail argument; those who design and implement this stuff are the ones who never end up as the sucker who actually has to work on this stuff, on a ladder, flashlight between your teeth.
We can all design cute stuff but go try working on the installation.
Some comments about MODBUS:
@ManAtWork posted the beginnings of a modbus RTU slave in Spin2 section here. Seems to be working with pc scanners..
It’s actually a fairly simple thing. Am starting to like it.
And, looks straightforward to covert to TCP…