BasicPI

PLC Power Modul

Posted on by Jan

This is the 24V power modul. It uses a 3rd party isolated DC/DC to support 24V “as is” and 5V isolated. It has protective diodes and capacitance for the 24V side. I could have needed more connectors for power distribution, but these boards are very small. As this is a PLC design we use. This should work on 12-24V and should be fine on the 18V batteries I use.

The remaining challenge is that the next modul is a Power Servo that require 8V or 12V depending on model. Even small, miniature Servo’s are a pain to switch on so these bigs ones will be a real issue. Learning from experience I believe it is wise to have a On/Off on the power to each servo as well as a current sensor and monitoring – which means I need to involve a MCU to do power management. This is all doable, but it add complexity/size.

The Power Modul above is the same as on the top, but without the isolated modul and with less internal power connectors. I can replace the Waterproof connector with an internal connector on 24V and adjust voltage out from 5 to 22V with 5A in peak, continious current. The DC/DC have a on/off switch, so all I need is to add a current sensor and an internal connector to a MCU board monitoring the PSU. This was a quick draft, so the modul is not ready. One issue here is that I use the same connectors for multiple things – that is OK’ich as we use TTL (5V), but it is very bad then we mix 5V, 8V, 12V and 24V – så I need to deal with that by using different connectors that cannot be intermixed by accident.

Protecting PSU’s from Motors are a big issue. I believe that the best protection is if the PSU have a fast, analogue trip that disconnect the PSU on over-voltage and -current. I can do thos in SW, but in this case I would like a analogue HW trip that need to be switched back on by SW. SW will be to slow for switching off. A misbehaving motor controller will typically trip and release the motor causing a break that release energy back on the 24V. This often result in a pulse that can break a few things. The PSU itself is the worst because as currend drop from xx to 0 it jump up in Voltage and uses a few “cycles” before it regulate it’s output at the same time as the Motor or coils misbehave. This needs to b experimental, but I think it will make the system safer.

PLC Ethernet Modul

Posted on by Jan

Picture below is an Ethernet modul. It connect to the PLC on the left side and have a waterproof Ethernet connector on the right side. Again I have replaced the SWD connector at left bottom with TC2030. I don’t expect to be using so many of these since CAN/CAN-FD is the primary link technology, but having Ethernet capability is a must.

The connector used is a M12 waterproof connector. I was considering using GX16, but decided not to due to lack of IP67 support + M12 have more combinations and is a bit smaller as a GX16 uses ca 8 mm more PCB space.

New Modular Control System

Posted on by Jan

I have done several experimental modular control systems that was scalable, small in size and based on MCU’s. My first experiment was with Basic PI Hats and I later did a smaller, modular system illustrated below. The system below was actually a great success. Specially the keyed connectors worked well. What did not work so well was the size, components on both sides, mixture of CAN/RS485, lack of galvanic isolation and lack of waterproof design. Using this on a mobile vehicle proved to be a challenge as I needed to create a larger, waterproof box around the cards. It become clear that I needed to address these issues and modify the system a bit.

The first change was to avoid duplication of CAN/RS485.

The second change was to replace LQFP64 with LQFP48 on MCU for the smallest modules.

The third change was full galvanic issolation on everything.

The fourth change was waterproof connectors and waterproof box design. Rather than using a random box I create my own.

The fifth change was to avoid two PCB’s on top of each other to get a lower design and avoid extra PCB assembly cost.

The result is still work in progress, but it is a flat, small, modular, waterproof control system that I can just mount directly on any vehicle and connect with plug & play cabling. The project boxes will vary and the Powerpoint illustration below is only a concept draft. The box is flat with connectors on two sides and mounting brackets on the others. Boxes can be designed to fit content – number of modules. The idea is that you have minimum wiring and only use communication & power until you are close to the actuator/sensor.

I divide units into two categories : CCU (Central Control Unit) and ECU (Electronic Control Unit). CCU is basically the core of a system, while ECU interface actuators and sensors.

My main challenge so far has been to decide on size, design and connectors. The module below illustrate the challenge:

This example module is 25 x 70mm in size and contains MCU, PWM channels, full galvanic isolation and waterproof connector so it can be connected directly to the panel wall. As you can see space is an issue. In my previous experiment I put components on both sides, but I decided to use only one side this time. One argument is lower assembly cost, but more important is the cooling system that the modules mount on to.

Someone will also notice that I have replaced the SWD connector I have used for years with a minimum TC2030 connector (left bottom corner J2). The cable cost ca 50.- USD, but as you have no component on the PCB it saves cost. I have seen these in use, but I have no previous experience with them myself yet.

GX16-8 Footprint and 3D

Posted on by Jan

I created the footprint for GX16-8 and updated the 3D with a few details. I will see if I can add the thread as well. I quite like these connectors, but I am a bit concerned that I only find them on one source on Aliexpress + I realized that these connectors have a different pin position than the “normal” ones. The later means I have no source for waterproof plugs as is. We will see what I do, but I will stick with these for now.

Below is an example of GX16-8 in use on an Ethernet module. The 3D model only lack the threads, but I will see if I can add those. These pictures are from KiCAD and the way I have set the projects up means I do a change, press a few update buttons and voila. And as said earlier – a 3D package on a electronic part don’t need to be perfect as long as the importamt parts are correct. FreeCAD and KiCAD both require some training and patience, but they both work great.

GX16 Connectors

Posted on by Jan

I fancied using GX16 connectors in a project since they are low cost, robust and can be made water proof. I found 2,3,4,5,6,7,8,9,10 and 12 pin versions with bend pins so they can be mounted directly on a PCB and fixed to a panel. But, what I did not find was 3D models for KiCAD, so I made my own. To draw the 3D package I used FreeCAD that is becoming increasingly usable. GX16-12 is illustrated below. After drawing this you export it as a STEP file and import it on the footprint in KiCAD. One trick I often use is that I focus on important details like footprint and in this case distance to panel. The rest is nice to have – the sylinder have a M16 screwing and a flat area on top that I have not added yet (saving some time for now).

Assembling in FreeCAD is not so bad, but you need to think about how you build your parts. In this case I have a part GX16-12 that uses multiple sub-parts. It was easier to assemble that way using an extension “A2Plus” + once one version was drawn it eas fast to make the other pin versions as the only difference is number of pins and where they are located + length of pins. I don’t draw in FreeCAD that often as I in most cases find very professional 3D parts and footprints on-line, but this will do.

What I do next is to create a test project where I mount the connectors and print the PCB on paper. As I have the actual connectors I test them to see if footprint and distances are correct. Hole-through are solid + in this case you also have a mounting to the panel.

GX16 is not adverticed as waterproof as it is a very robust aviation connector, but you can add rubber rings to make the socket itself waterproof. The plug is a bit more complicated as you need to buy waterproof versions (and they exist). The reward is a low cost waterproof connector. I considered other connectors like M8 and M12 series – I really like M12 series, but prices for M12 are up in 30 to 50 USD on some of the connectors.

BSA – PLD Flow Editing

Posted on by Jan

This diagram example consist of two different component types. The PLD state/event symbols have a free connection and atop-down flow, while the ComLink have 5 fixed connections in horisontal path with clear marking on where the events are. To connect you just click on the event circle and drag the mouse to the next symbol – so far, so good. One challenge is the conflict between vertical and horisontal diagrams – in this case I need to move the fixed connections on ComLinq to top/bottom. I also realized that I could delete a flow a bit too easy on ComLink + I sometimes get conflicts beween selecting lines and connection points. These details in BSA are important as they affect your speed of work and will need a bit of work/consideration.

Real Life events have stopped my progress on my own tools a few months, so it is time to ramp up a bit and finish. BSA itself is not that far from being available for early Beta testing, but I need to do a lot on the actual PLC.

A second, related concern isa recent change I did – I liked the connection points so I forced the sub-diagram to always have them as a test – you now need to modify the diagram or add methods/events in the property list before you connect – you cannot just draw a line (flow) from one component to another and connect ad-hoc anymore. This works fine if you have a fixed number of connections on a pre-made diagram, but I did not like the result. I miss the capability to you draw flow as I go and expect methods and events to be created. But, how do I avoid creating new ones by accident?

It is times then I want fixed number of methods, events and times then I just want to add them as I go. Again – it is related to speed of coding – how fast you get things done. This part of BSA is a bit try and failure. Keep in mind that flow between components is connected to an event and a method with parameters that might need conversion. If you create a new method by accident that also create extra work. A third concern is how to visualize the parameters and parameter conversion.

An event have parameters and a method might have different parameters causing a conversion. This is a lot of hidden information behind a small blue line that we somehow need an efficient way to see and edit. One option is something like the one below – you force a PScript or conversion component if parameters are not 1:1. And if they are 1:1 you can optionally have a list printed associated with the line. One option is to add a symbol on the line so that a conversion box can be hided/expanded because this is also details you don’t always want to see as they will complicate diagrams.

These details are a bit hard to get right as you often have to code an example and test how it is to work with before you decide. I will continue this related to flow lines because they are  critical for the tools productivity effect, but I also need to get a first version of this tool on the road soon.  In fact I could need 3-4 developers working on this alone. That day will come.

Thanks for reading and I promiss it will be much more material here the next months.

Mobile PLC

Posted on by Jan

I have lately had the priviledge of working with two vendors of mobile, electrical vehichles – one used a self-developed system designed for volume production series, the other was a larger industrial vehiche on prototy level where they started with a standard PLC and a small cabinet. Usage of a standard PLC “kind of works”, but you get a few challenges:

  • Size – A standard PLC needs a cabinet and a lot of boxes to deal with all the sensors on a modern vehicle.
  • Cost – each module cost from 100.- up to 5000.- ++ USD. It add’s up far to much.
  • Functionality. A PLC is supposed to be easy to assemble and code, but old PLC systems might have limited capabilities, slow responce times and limitations on custom functionality.
  • Lack of optimized volume production.

Some PLC vendors have worked on this and try to create smaller and more modular systems like the one I designed on this channel earlier. My latest PLC experiment was actually a big success, but it needs a few improvements. Having a Motherboard with add-on boards are great, but I can’t mount that onto any robot as is – I need to design a water proof box and I need to think about cables and noise.

First – lets discuss what a PLC actually is: Myself I am a software engineer more used to C/C++, electronics and embedded systems – basically I have spend a lot of years creating PLC modules as that is what they are. A PLC is only a nick name on off-the-shelf electronics that can be assembled and have a system to configure/code them to custom usage. An Arduino is in many ways a much better PLC module than many of the professional ones. But. PLC developers are also very focused on getting the job done and having a reliable installation. If you automate a factory with plenty of space you simply do not have the time to make custom electronics. But, if you design a product that will be selling/installed in volume you will be interested in two objectives:

  • Getting the prototype assembled fast due to time to marked factors. An experienced developer knows that a product will not be 100% the first time because as you build a prototype you learn how to do it properly later. This learning is very important for the success of your product and so is also time.
  • Having a path to a more cost optimized volume production.

The last PLC system I experimented with is a success as it offers this. It focus on size and special needs for larger drones that also apply for mobile vehicles. But, we need to move on and learn from the experiment to create a real series. I have summarized some lessons learned below:

Lesson 1: I used a small 45x25mm format. I need to increase the size a little so that modules have space for galvanic isolation. Mobile equipment have a lot of wiring and a lot of motors that will cause issues, so we need galvanic isolation on everything.

Lesson 2: CAN, CANopen, J1939 or Ethernet only. Wifi, BLE and LoRa is nice, but you can only have one of these activeCAN is excellent due to fast responce times and easy wiring of networks. CAN-HS is good, CAN-FD is even better. CANopen uses CAN 2.0A while J1939 uses CAN 2.0B so they work together + using standards means you can plug in 3rd party components then needed.

Lesson 3: Boxing and standard cables – minimize the need for actual wiring work. Use maximum plug & play to reduce hours needed.

Lesson 4: Galvanic issolation on everything. Modern electronics have a lot of new spece/cost optimized components for galvanic issolation, so lets use them.

Lesson 5: Motor noise – noise from multiple PWM wires needs special attention and wiring.

Lesson 6 : We need optimized motor controllers – Optimized in size. You can buy imverters, but they are often big and not to efficient. Cost is one issue, but space is critical – inverters tend to be much larger than optimized motor controllers. Also be aware that some car manufactores actually sell their car parts – motors and motor controllers at decent prices.

Dealing with electronics you will need someone to produce that electronics so you can buy it and use it. So having a modular, size optimized PLC alike system is worth a lot for prototypes. They allow you to assemble something fast and they allow you to change designs and adapt fast. Once you have a working prototype you should be able to create custom systems with a minimum of extra hours.

Software is a different issue. A classic PLC design is expensive in licensing and sometimes very limiting. In my opinion we often pay a lot for very little. You have close to no freedom using a classic PLC. But, that is where BSA comes into picture. BSA (BasicPI System Architect) is a more classic CASE tool where you have tools to create C/C++ code and use a mix of technologies to increase the productivity of a developer. It also merges the world of a old PLC with modern Software Engineering. But, most important of all – it has been carefully designed to have no limitations – if you want to write assembly or C/C++ go ahead – it is up to the used to justify your own time usage.

What I am considering is (1) Continue on BSA with more focus on a new PLC system, (2) redesign a modular PLC with learnings in mind and (3) start looking at motor controllers as part of a larger system.

Thanks for reading my early morning ranting – and I apologize for all the typos caused by a Norwegian writing English 🙂

Robotell USB-CAN Adapter

Posted on by Jan

I bought a few of the cheap Robotell USB-CAN Adapters fro Aliexpress and finally decided to use them on a project as I needed a low-cost PC-CAN Adapter. Someone will recall I made USB/CAN Adapters some years ago using STM32F105, but I had so much trouble with those that I never used them. I have on the agenda to create a proper isolated one using STM32G431 that can support CAN-FD, but that is for later. The first challenge with the adapter below is to find a driver and doxumentation – once that is done the adapter was straight up working.

Documentation : Robotell CAN-USB interface – python-can 4.2.2 documentation

For test app search for “RobotellCANMonitor”. Myself I don’t care about Python code as I want proper code in C++ or C#. The USB is a serial port in this case that will install directly on most PC’s – it did on mine. The USB is in this case just a means to connect to the PC, so for all practical purposes it is a serial port. I use C# a lot for top-side so it makes sence creating a C# driver. As for top-side tools I need two – one is a test tool using the driver and USB_CAN to communicate “CAN” to the devices, the second is a CAN Analyzer.

My initial test setup is two adapters in loopback as I write/test the C# driver. Writing a CAN Driver we need to start by normalizing the API because we don’t want a different API just because we later change the adapter – the interface we want is CANbus:

  • API to send/receive raw CAN Frames.
  • API to open/close driver on Serial ports.
  • API to set CAN configuration on top-side.

The USB/Serial thing in the middle is just a link, so we want to insert CAN in one end and get the same CAN message in the other. Robotell uses a byte frame as follows:

  • 2 bytes 0xAA as start mark
  • 4 bytes ID
  • 8 bytes data
  • 1 byte DLC
  • 1 byte Message Type (00:CAN. FF:System)
  • 1 byte IDE Flag
  • 1 byte Request flag
  • 1 byte CRC (Simple addition – exclude Frame Control, start and stop marks).
  • 2 byte 0xFF to mark end.

Note that if the array consist of 0xAf, 0xAA or 0xFF another oxA5 (Frame Control) must be inserted in front.

Note:As I receive frames the tart mark is 2 x 0x3F. To loop the same message back I must modify these to oxAA.

Assuming you use System Message you can replace ID with the following:

  • #define CAN_BAUDRATE_ID 0x01fffed0
  • #define CAN_CPU_INFO0_ID 0x01fffff0
  • #define CAN_CPU_INFO1_ID (CAN_CPU_INFO0_ID + 1)
  • #define CAN_VERSION_ID 0x01ffffe0
  • #define CAN_INIT_ID 0x01fffeff // Clean Flash(500,000 bps/mask 0x0000)
  • #define CAN_FILTER_BASE_ID 0x01fffeeX // X=0-F(Mask Index)
  • #define CAN_ABOM_ID 0x01fffeb0
  • #define CAN_ART_ID 0x01fffea0
  • #define CAN_RESET_ID 0x01fffec0 // Reset

Set baudrate

  • Replace ID with CAN_BAUDRATE_ID
  • 4 first bytes of data is speed.
  • DLC=4
  • System Message

1 byte CRC

For more details see this: Robotell-USB-CAN-Python/Robotell_USB-CAN.txt at master · nopnop2002/Robotell-USB-CAN-Python · GitHub