The more I look for any real standards within PLC the more I get the impression that they either do not exist or is not used. This is consistent with what automation engineers tell me. I was kind of getting my hopes up with “Industry 4.0”, but well… lets crack on with creating our own.
PLC Modules
The first PLC module I want to make is a box that can hold Raspberry PI + 1 or 2 Hat’s. Having the capability to add a RPI 3 or RPI Zero W is a great asset. It also provide a solution for industrial mounting of a RPI.
This enables 4 PLC modules “as is”:
- Linux/Windows computing module
- 5 port RS485/CAN communication Gateway
- 16 channel Servo/IO
- 8 channel DC Motor, 8 channel Servo/IO
I will create more Hat’s so they can be added as PLC modules as well. I am a bit wage on the details around how to integrate Raspberry PI itself. I want PLC connectors in front and that leaves Ethernet + USB at bottom. The more problematic side is accessing the backbone – suggestions are most welcome.
Micro PLC
Maxim Integrated have started a PLC series called “Micro PLC” – the boards have a similar concept with STM32 at core and a backbone bus – except for that I don’t know much about them. It is a cute concept.
The system have several boards, the one above is quad channel analogue input. . I get the impression that the purpose is more to demonstrate Maxim technology than to create a PLC system thought, but who knows.
Plain VM – Instructions
The blog entries show how Plain VM/Assembly evolved, but they can be a bit confusing to read stand-alone. So, I need to clean-up the content here a bit. The exercise now is to write up Plain Assembly Reference, Plain VM Reference and make sure the two documents are synchronized and consistent. I had a working core before, but need to change it to adapt to my latest ideas. Looking at my first register only VM I admit that is much simpler, but I am really keen to get instructions like Transaction and syntax supporting distributed processing and parallelism going. Below is an updated VM Instruction table – the text is fresh from a libreOffice document that will be uploaded later.
| Assign | Assign an expression to a variable. Execute a pre-parsed expression tree and store the resulting value in a variable. Expression can either be written as an algebraic math expression or a list of simple operations separated with ; |
| Call |
Call a function. Call creates a return entry on the stack and will continue with next instruction as End of the function is reached. Call can in contrary to raise also capture event’s raised by Raise. |
| Decode | Unpack a bit field |
| Encode | Pack a bit Field. |
| End |
End a conditional block of code by jumping to a pre-calculated ix on the stack. For (as an example) will insert it’s own ix on the stack, End will jump to that ix and remove it from the stack. |
| Exit | Exit the VM. Will terminate the current module. |
| For |
For Loop. Will create a stack return entry causing the next End instruction to jump back to the loop start. |
| If | If statement to allow if..elsif..else with expressions. |
| Nop |
No Operation. Basically not needed except usefully for testing basic performance. |
| On |
On capture event’s raised by a Call or State. It contains parameters defined by the Event definition in a Func. |
| Raise |
Call an event with parameters, but without creating a return entry. Raise remove the stack, but will leave the stack entry point. The next end will return to the last “call”. |
| Switch | Switch to a selected value. |
| State |
Will wait until a listed event is raised before it process that event and continue. |
| While | Loop while an expression is true. |
| Transaction |
Lock access to listed “interface” variables. Transaction will wait until access is granted or we time out. Transaction can also “spawn” in which case the transaction block is treated as a function in a different, local module that execute in parallel. See instruction Spawn. |
| Update |
Update complete a Transaction by either Commit or Rollback changes. |
| Commit |
Can be called separate inside a Transaction block to commit part of the changes made. |
| Rollback |
Can be called separate inside a Transaction block to reset changes made. Changes are reset to the last commit. |
| Spawn |
Spawn call a function located in a different module. This function is executed in parallel and the returning event is inserted into our event queue. |
SoC is easy
I see a lot of schematics and people who struggle with getting a STM32 working. I have only been working with F0, F1 and F4, but these SoC (System on Chip) MCU’s are dead easy to get working.
Basically they have internal oscillators so they only need 3.3V power. The F4 range also need VCAP capacitors – the number vary from MCU to MCU. F411 uses 1, F405 uses two etc – so check your datasheet it is well marked. I always use SWD, but you could also use Serial, SPI or CAN for downloading code. The capabilities vary from MCU to MCU, but I like SWD because it is only 2 pins + NRST + GND.
The important thing is – connect power and you should be able to download code. The main reason I struggle is short-cuts on PSU lines, so once you ohm your 3.3V ok – just expect it to work – repeating myself – it is very easy to get a STM32 ticking!
Rx Breakout Board
This is a STM32F1xxRx prototype board I made for my own usage. I will update with VCAP capacitors for F405 and see if I can produce some of them in F103, F105, F107 and F405 format.
I was very annoyed as I got this one because I realized I had sent in revision 1.0 while I already had made a revision 1.1. Not that it mattered much – it did it’s job. This one is mounted with STM32F105RB. The new one have a few more leds – correct some markings and width + I will add vcap’s. The design of this carefully so all pins are available – I will add jumper for the internal leds. It also uses our standard SWD connector.
Just for the record, you do not need to add the SWD connector – use a SWD adapter with male connections and just press them down the holes – it allow you to program the boards without adding a connector – quite handy for later production.
PLC Modular System
I have worked far to long with 19″ cabinets and things you mount from front, so what I am thinking is a micro-version of a rack system. We box each electronic module with a backbone plug and custom front connectors. We then plug them in, wire using standard wiring (that we probably have to create) in front – no wiring in the back.
These boxes are simple and can easily be printed on a 3D printer. They will also allow us to mount more electronics tighter to address the total size.
A classic PLC uses 2 wires for a 24V pulse signal – we can typically standardize these so that we apply standard, plug & play cables and avoid as much custom wiring as possible. The top front is after all for wiring to equipment, not for internal wiring that is already done in the back-plane. I think this can work, but I need to talk it through with professional automation engineers – luckily I have access to them in numbers.
One drawback I can see straight away is vibration. I was planning to make this so small that it could fit mobile Equipment, but mobile Equipment vibrate a lot. We will need an outer box and holding mechanism that tolerate very high vibration – or more correctly reduce vibration.
PLC Project Box Option
Finding a standard project box for PLC is not difficult. The box above is available from 1.5 GBP and up on ebay. They have a standard click on system in the back for wall mounting and opening on the sides for connectors. This is quite popular within automation that mount these side by side and have cabling above and below. The illustration below show the main principle on how they are used
I ordered a few of these earlier, but gave them away because they where to large for what I planned at the time + I would like to avoid the need of loads of custom wiring. This is still an option, but I would like something a bit more plug, play & modular.
Automation engineers would love this type as they are used to it, but if you scale up modularity with rather large boxes you also need a large cabinet – I like to address less space usage and less cabling needs. We do after all plan a backbone bus that is not present in classic solution,
PLC System
Just an early block diagram with some ideas. I plan a backbone bus with Power, Control, Data and Address pins. No MCU on the backbone, but should be clickable into PSU modules at each end + be extendable by 4+4+4…
A motheboard with Ethernet, Wifi as a GW to normal network using the same form-factor as a sub-board – Can also act as a stand-alone RS-X gateway. One of the PSU units can be a battery etc. Many nice options here, but need to play around With ideas for a while.
The bus will probably contain
- Power
- Battry
- 4 x Serial (RS-X)
- Control
- Data
- Address
STM32F405RG Working
I purchased 2 separate series of 5 MCU’s – the first had weak marking and did not work on a previous breakout board, so I ordered a 2nd batch. The 2nd batch had nice marking, but after trying 3 failing MCU’s I wanted to try the old batch – and voila – it works. The breakout failed because it lacked the VCAP capacitors.
I am also pleased with the new soldering technique that I discovered – I assemble the LQFP’s with close to no error now. Much easier to get right. What I do is to apply paste, but it is always to much paste so I scrape it back of leaving only a thin surface. Once that is heated I use a soldering pen to drag tin over the pins – it is fast, simple and easy to get right.
Regardless, I am very happy to finally see STM32F405RG working! It is to early to conclude that I had a bad batch – I want to try some more before I conclude. Having a working ST32F405 means a lot because it is proof of concept allowing me to plan on using this. With it’s faster processor, 1Mb Flash, 196Kb SRAM it is quite a step up. This reminds me of another silly issue – I have measured the Crystal, but realized that I was not using the MCU’s at full speed due to wrong setting – wow – just felt as if the Turbo hit in.