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.
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. |
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!
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.
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.
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,
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
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.
PLC (Programmable Logic Controllers) have been around for years. It usually is a modular system of electronic boxes with IO capabilities that can be assembled into a system for automation purposes. PLC have 5 “standard” languages that are not really that much standard. The standards tend to serve as minimum list of features, but as the vendors add much proprietary stuff the PLC applications end up being very proprietary. Plain have a much higher possibility of actually being portable.
A PLC system cost a lot of money, but as making custom electronics and writing code in C/C++ cost more the vendors get away with high pricing on electronics, tools and HMI. Also – the hard fact is that it is not much I can do with a professional PLC that I can’t do better, faster and with less cost using Arduino or Raspberry PI these days.
I have briefly mentioned HMI – I will return to that later. But, my Raspberry PI Hat’s and RS-X modules powered by Plain is an excellent PLC substitute. I do however fancy a more dedicated, modular system that can compete with classic PLC in a smaller space. My Hat’s are great, but it’s limited what I can create on the size of a Hat + the Raspberry PI is often not needed. I want to keep the option to add a RPI module with a Hat, but I want a new system.
Using Ethernet as backbone I would like to create a motherboard that control 4 x IO modules. Using RS-X as bus allows me to use the modules stand-alone or plugged them into a assembled system. Adding more motherboards I can scale up with 4+4+4+ modules as much as I have space. I believe I can do this on very small Space.
The major restriction I have on the Hat’s is connector space. I want to use standard connectors with standard cabling to avoid the need for custom cabling as much as possible. My “PLC” language will obviously be Plain.
What needs to be different from what I have done so far is Galvanic Isolation on all communication to limit the chain reaction if something backfires – because it will!
The added work-load on coding does not worry me because we can re-use things that I am in the process of creating anyway + I think this will be fun. 10 x 10 cm comes to mind as a size factor. It is easy to create modules that are 5 x 10, 10 x 5 or 10 x 10 to be mounted as part of the same system so it gives us freedom. It is also easy to create a 10×10 carrier module for Raspberry PI so a RPI+ Hat’s can become a module. But, I will look for standard, low cost project boxes before I decide on size.
It will be fun if nothing else and thats why I am here in the first place, so lets crack on with an open source, home made, low cost PLC system. My home is an excellent testing ground – assuming it don’t burn to the ground in the process 🙂
Wow – it is actually ticking -at least blinking the leds. Been a bit forth and back – this is a STM32F105RB – I connected it using zero resistors on the VCAP as I could not get STM32F405RG to work. Turned out the problem seems to be my Mini ST-link’s. Well be back With STM32F405RG, but this was a struggle to get ticking!
Update (28.mar.2017) – F105 working well, but F405 still not ticking. According to my notes the only difference should be two capacitors from pin 31 and 47 to ground. My challenge with this board is that it is quite small, tight and contains 7 new modules that I have not coded before. This could be a test of my electronic skills.
I still suspect bad soldering that tend to be the case – this is the drawback with hand-soldered prototypes – so I will make a fresh attempt later – these MCU’s have been dead easy to get going so far – connect power and a SWD and your up. I can’t complain – I had a pretty free ride getting very over-confident so far
Update (29.Mar.2017) – It is still a mystery why the F405 will not work. I applied the 100nF capacitor on NRST, but it made no difference. I did however discover a soldering technique to minimize shortcuts on these LQFP packages. As for the board – F105 is working perfectly if I replace VCAP capacitors with zero resistors, so the board is ok – I don’t need the F405 for this board, but I wanted to test F405. I still have a few things to try. I have MCU’s from two batches, so I will start fresh on a new board with a different MCU batch later.
After that I will update my Rx breakout to have VCAP capacitors and jumpers to use both F1 and F4. It should be this simple. A breakout board is better to do this level of testing on as I need a proof of concept on a F405.
I did test my ST-Link on a F407 and it worked fine – this is more or less the same MCU. The initial error was “No Communication”, but as I removed one MCU and fixed a shortcut the error change to “Failure on Flash Erase” – I have seen this on other board that I later got working with F105 as well. This means it has some initial communication with the MCU, but the erase operation fails. If I skip Erase it fails on Program – it sounds like an incompatible protocol.
I have four suspicions: (1) Bad/Fake batch. I am buying from various sources on-line to get samples at a decent cost, but I have so far never had a problem with this. (2) SWD wiring to long for this MCU, (3) my ST-Link is incompatible with this MCU batch. I somehow don’t think so since the F407 worked with the same wiring, but you never know. (4) I will try different capacitor sizes on the VCAP.
I would like to update the Rx breakout anyway, so I will order that and see how we can move on. I also realize that I need to add a few extras to make it easier to scope these boards. I am notorious for not adding test points on early proto-types and I just paid the consequence for that.
A 168Mhz design is a bit more than I want to do. But, all the high frequency stuff should be on the inside of the SoC in this case. The issue with high frequencies is that lanes start to behave more like capacitors and coils by accident, so you need a much better analogue skill-set and awareness of what you do on PCB routing. To my knowledge this should not be the problem, but at the moment I need to question everything.