“Presentation” or “Logical/Conceptual View” is seldom added to modelling tools. The example below show a raw table with a lot of attributes, but as we use that we might want to present fake attribute or just a simplification of the raw table adapted to the current diagram. This is still the same physical table, just “presented” for the purpose added readability in a diagram. This will be supported in BSA – we need it otherwise the class sizs will be huge and diagrams useless.
BSA is coming together, but it’s a lot of work. PLD in full effect will take some time, but the UML support is close to finish. This is the bit I miss the most myself so I will release an early version that support the UML design part. What you see below is a simple class diagram. PLD and the compiler (Code Generator) will take some time yet, but that don’t stop us from using the design parts. I will primarely support UML Class Diagrams and UML State Diagrams (PLD). PLD have the building blocks from a UML state diagram mixed with elements of SDL (Specification and Description Language).
This is a very powerfully PWM Output Module with Encoder input. It is capable of 4 independant Half H-Bride, 2 x DC Motors or a full Stepper at 10A/24V. At least the electronics will manage a lot, but supply limitations and pin limitations means it will be a bit more limited, but yet. The primary usage is Stepper+encoder or DC Motor + encoder. The module also contains current sensor and i fully isolated.
The target motor shown below it is a small, powerfully DC Motor with a 90 degree hear and encoder that I want to try out on a 4×4 robot. This is low cost component and I believe it has sufficient torque and accuracy. Using a modular PLC concept I will then have a 4(5) slot box with 1 CAN port, 1 power input port, 1 DC motor with encoder and 1 Power Servo driver. I don’t need 4 channels PWM in this setting, but one option is to upgrade to a Nema17 based solution I tested earlier. Nema17 with 90 degree gear works, but it is a bit noisy + expensive. The connector is a 8 pin M12 using 4 pins to encoder and 4 PWM output channels.
My 3 slot CCU is overkill on this ECU, so I will make a single slot CAN port or maybe a 2 slot CAN + PSU – lets see. The PSU in this case will be a 18V 4AH battery.
Looking at my CCU board I have 4 components that are of concern related to vibrations! Top-Left I have a USB connector, but this is for development only so it will not be mounted in production. Top-Right I have DC/DC and connectors that might need support. And in the midle I have done a mistake as I added an old 32Khz crystal for RTC just because I had it in numbers – this is a hole through and the body/legs will be exposed – this I will replace with a SMD component. As for the connector and DC/DC I might need to add glue or supporting mass as I expect that long term exposure to vibration might cause issues.
The next question is if I can use a large speaker and create my own test bench for vibrations?
In my last entry I wrote about challenges with sizes on opto-couplers. I have since discovered isolated digital IO modules with twice the density compared to opto couplers. They also offer 100Mbps speed and bi-directional solutions.
I recently used a version of this motor/gear with a Nema17 tor run the wheel on my mobile CNC machines and while it works fine it creates a problem : sound!
The printed plastic parts are hollow and a stepper motor vibrate a lot as it steps. This creates an unexpected load sound. The solution is a classic DC motor with an encoder (above) – I hope. Either that or see if I can mount some sound isolaters on the Nema17. I like the DC brush onces above thought because they are also smaller and more cost effective, the issue is if I have sufficient control of movement as with a Nema17. We will see.
One repetive issue I face is number of signals from MCU to/from IO that can be isolated. The the case below I want 7 digital signals and an isolated current sensor back, but I lack space for the 7th signal since one module is 25mm in width. One solution is to mount components on the back side, but I prefer to avoid that for a specific reason. Another solution is to make the isolation barrier different or simply ditch one of the signals… I am looking for opto couplers that use less width as well…
CCU (Central Control Unit) is the name I give units that contain the core “brain” and only communication IO. The module below is an example of the core of a CCU with 3 external CAN ports, 8 internal module ports and 2 external Links. This is a fast MCU with a decent amount of speed, SRAM and Flash + it has it’s own SPI Flash + a USB for debug only. The CAN ports are standard M12-5 A Code and wired according to a de-factor standard. These will be used for CAN and for RS485. Possible I can use B or D-code for RS485.
Links can be used for modules as well, but they are designed to be links to different CCU’s allowing them to be connected in series to extend the CCU or linked up as a redundant unit. The unit above takes 5V in, so it is dependant on a 24V PSU unit.
The board above can be used alone or connected to a range of IO modules with different capabilities to form a larger CCU or even a ECU (Electronic Control Unit). A system will usually have one CCU and multiple ECU’s, actuators and sensors. As a rule we use CAN on everything and only RS485 or Ethernet as an exception. We can also use RS232 and other techniques as needed.
Each module is 70x25mm in size. The CPU module occupy 3 slots and each module can occupy as many slots as needed + they can double length to 140mm or even larger with special cabinets. The core is small project boxes that can be filled with modules as per need to form a custom PLC.
I use the term “PLC” because a modern PLC is mostly the same as above with specialized SW. My PLC languages will include C++, C#, Rust and Python + it will be supported by BSA. In reality I will be coding drivers in C++ and logic in PLD, but that is my choises – it should not limit you. The objctives is small size, plug and play and low development cost. In short you pay a few bucks for a few HW units, connect them together and will be up running in no time with a prototype or completed project.
This block diagram illustrate a CCU. A minimal CCU is only PSU + CPU module with 3 x CAN. A maximized box can contain up to 8 modules and as the MCU itself can act as a module it is basically no limit on how much you can put into a box.
CCU – Central Control Unit. Basically system level logic and communication.
ECU – Electronic Control Unit. Basically a box with a CAN connected to a CCU controlling electronics directly.
Minimal project box to hold a small PSU and Motherboard with 3 CAN ports. Tested a few boxes already so this will work out fine, but it is a lot of details to get right.
As we move a servo it would be more than nice to have a position feedback! The servo itself have a potentiometer telling the absolute position, but a standard Servo only have a 3 pin interface Power and Position setting – it gives no feedback. This is a common issue with many available actuators – lack of feedback.
In my case I want to use a power servo to turn four wheels and without position feedback I will be part blind as I drive. Or am I? I do not have the actuator position, but I have current feedback and know that high current usage is an error situation. Secondly I have GPS, accelerometers, magnetometers that will tell me if the vehicle is moving as expected then I drive.
That said – I am considering adding position feedback on the steering as well, but I will return to that later.
Creating a module that can control a PowerServo is fine, but what about using it from BSA? What do we need to do? From a user perspective very little. In this example I just created a PLD State Diagram block with 3 input methods and one output method. It is this simple once the underlaying library is set up. It is simple and fast.
Comparing to some classic PLC systems BSA is a dream to work with in development speed, but BSA target far more than these old systems as well.
The only limitation in this case has to do with the servo – normal servoes allows you to set a position, but they give no feedback as to what the actual position is. You do however get the current usage as feedback and we know that if current usage is high it means the servo struggle to reach or hold the set position – this is thanks to the added current sensor on the servo modul.
In a final version we just add the servo modul as a library component that will pop up at left as if it was a build in tool. As we code we will drag lets say 4 servoes into a diagram and code their behaviour. As we deploy the code we need to associate those 4 servo blocks with physical servoes in the config. The servo modules will pop up as unallocated resources and we just need to tell the system what component they are in our diagram. The rest is magic plug & play.