BasicPI

PLC – Ethernet Module Draft

Posted on by Jan

The nice thing about KiCAD is that you find free 3D models for almost every package. Imported a Step file from GrabCAD, made my own footprint and voila. It is a bit space between the PCB’s as the header is not showing, but it gives a good impression of the result. If I want to use the space below the W5500 mini module I basically need to use the back side. In short I can probably add some optinal stuff here like SPI Flash and a serial port tranceiver.

This is with a LQFP64 version of STM32G491, so it will be tight. But, I have 20 of these and are unable to get hold of the smaller LQFP48 so I want to make an attempt at least. Would be nice to assemble these before x-mas. Give me a few hours and I will have the full module.

It’s been a while since I used KiCAD, but the interface have improved and it is nice to see that KiCAD more and more is on the list that is supported by vendors.

PLC – Ethernet to Serial Converter

Posted on by Jan

The two first modules I will create is Ethernet and Serial (RS485 & RS232). I have several paths forward to create this, but the most obvious is to create two modules that can go back to back. To connect these two I use a small PCB connecting CAN on J2 – the four pins are 3.3V Power (or 5V ?) and the two CAN pins. The bus board can hold the PSU and lanes to interconnect CAN between boards. J2 is on the top at left side and bottom at right side.

Another option is to use the space under the Ethernet Module (or back side) to have a serial out through a low profile mini-connector directly on the Ethernet module. This will make a very small all-in one PCB. Yet another option is to use an UART TTL back to back. The UART is nice for debugging, but could also connect directly between two boards with a jumper. I need to actually make these boards to see how much space I have.

The advantage with the Bus board is that I can put PSU here – the alternative is to put PSU on each board – which can be assembled on the back.

The main drawback right now is that I only have LQFP64 MCU’s in stock – I managed to buy some a bit earlier, but getting hold of any STM32 these days is difficult. That also goes for semiconductors in general andit seems as we will see 2024 before this get easier 🙂

PLC – Ethernet Module

Posted on by Jan

My KiCAD skills are coming back – just a quick check on the Ethernet module. I reduced MCU to LQFP48 and used a W5500 module through headers. I moved drill holes to the corner. The J45 in the middle is just for show. This is a 25mm x 45mm module and I will have plenty with space by the looks of it. This is good news. I need to squeeze in a x-tal, SWD connector, CAN Tranceiver and connector, but that’s doable. To squeeze in FRAM – not sure, in which case I store config on an internal flash page. My Ethernet to Serial modules from AliExpress are smaller than this, but I got a STM32 I can program and mounting holes 🙂

I will make one module using the W5500 adapter shown above – hence the pin header. On a later module I will use a low profile RJ45 and W5500 or W6100 chip directly – or I could use a MCU with an Ethernet interface. W5500 will give a max of 15Mbps speed. With a backbone bus of 5Mbps that is more than sufficient.

Above is a comparizon of some of the PCB sizes I can use. On top the Ethernet Module with the size of a LQFP64 outlined outside the LQFP48 footprint. In middle a dual width (90mm) module  and at bottom a dual height (50mm) module. This is just to give a brief idea of how much space that is available for IO. And the beauty of this system is that I can continue to scale up.

BSA – Using the PLC

Posted on by Jan

BSA will see the PLC modules as a named tree and the diagrams send/receive messages using those names as addresses. You will have the option to design and/or detect a tree.

easyIPC contains a config system allowing new, unknow modules to be reported and the user can then assign that module to a named position in the system. To do this the new module must fit the spesification for the designed system module.

Modules can communicate with eachother, but by default they will not. The config will need to set up the system diagram where selected messages from Module1 is read by Module2 as an example. Configuration here is done in two steps – first you create a system in code, secondly you assign modules to take up positions in the network.

 

 

 

 

Modular PLC – Part 3

Posted on by Jan

This just a mock-up of an actual module assembled from 7 IO modules using the later design. Size is just illustrative as I play around with ideas. I am waiting on project boxes and will adjust everuthing to that.

So far I have only draftet connectors as 5P headers. I am thinking about doing CAN only and maybe let each board have one connector that plug into a adapter board at bottom that fit into the project box. This would be a PCB only to create a backbone bus with Power and CAN-FD. The entire PLC will be flat, low profile. Using this system we can deliver modules that is 45 or 90mm wide and 25,50, 75, 100 aso in Height. CAN-FD interconnect within a box and from box to box.

It is possible, but I need to think about the mechanical solution here. An Alternative to having a Bus-board at button is to create a cable-PCB and soldier a specialized interconnect cable for each box. The advantage is lower profile, the disadvantage is more manual work. Cost wise it is more elegant to just plug things together.

Modular PLC – Part 2

Posted on by Jan

Sadly the headers occupy ca 10mm of 25mm, so to get Ethernet RJ45 fixed I needed 35mm width on the modules. The MCU module will be fine, but having two IO modules will require more space. 10mm extra is not the end of the world, but the design draft is also 4 PCB’s per module, so I wonder if I could get cost and size down by making modules with MCU on as follows:

The issue is that getting rid of the headers and reducing from four to two boards are fine, but with the target height of 25mm I still use up to much on the mounting holes.. M2 Mounting holes with 1 mm clearing is 4 mm. I also only gain 5 mm on width while I suddenly have to find space for the MCU. I can use a smaller 48 pin MCU rather than a 64 pin, but the saved space is scarse.

The disadvantage of doing this is that 25mm height will only serve the smallest modules. Another disadvantage is that we add a MCU on each module doubling MCU cost. And I don’t realy have a solution to interconnect boards here yet.

The advantage is that we reduce from 4 PCB’s down to 2. Interconnecting two modules are done elegantly on back to back using a UART TTL since you will automatically cross Rx/Tx. Another advantage is that we in case of space starvation simly can customize the module by (1) using 50mm Height or the full 90mm Width. Below are illustrations showing 90 x 25mm and 50x90mm.

I was thinking of using a TTL Uart between two modules mounted back to back, while I still use CAN for modules in general. Using a TTL UART is free – no space except for a back to back connecter. But, CAN-FD is also extremely small size with SO23 package Tranceiver so I could use CAN-FD on everything. All IO between MCU and IO is now custom. To faciliate Ethernet and Wifi I could sacrifice one mounting hole, but with scalability in Height/Width I am not stuck to the minimum size.

As mentioned before 90mm is selected because we can use standard PLC Boxes where you can have connectors on both sides.

—

A word about KiCad and why I do the mock-up in PowerPoint: I just upgraded to KiCad 6.08 and it’s been a while since I used KiCad so I need to re-learn the PCB tricks. KiCad is great then you know it and use it often. I will return later with more accurate mock-up’s on the mechanical design.

Modular PLC

Posted on by Jan

I was recently asked to create a PLC in the form of a cable and the resulted draft is quite awesome. The design size I decided on was 90 mm x 25mm x 25mm. The reason for the 90 mm is tto have a fit for standard PLC boxes. 25 x 25 is a reasonable target. This led me to create a motherboard with 1 x IPC connector and 2 x IO modules

The Motherboard uses 70mm leaving 10mm each end for full height connectors. The total length then become 90 mm as we adapt IO modules. Counting a reasonable pin excanche I settled on a 40 pin 2.54 pitch header supported by screw terminals for now. The connectors are mirrored so that modules can be mounted on either side.

The small 1cm connector in the middle is an IPC adapter allowing me to connect MCU boards together. And this means I can scale as much as I want. I drafted a 2 x 5P x pin header for now. I might add a screw hole. But, I might also mount the IPC directly on the motherboard.

The Block diagram is below. I have already tested pin layout in Cube, but it will be some tricky PCB routing here so I expect 6-8 layers on the MCU board to achieve signal integrity.

As for IO Modules I decided on a few issues that still is on draft leve:

  • Connectors are identical and mirrored, so a module can be added on either side.
  • Key is X pins that identify the sub-connector. I would like to have this, but I am running out of pins so will have to work on this.
  • 1 x CAN-FD TTL on each side. And a 3rd on IPC to interconnect several boards as one solution.
  • 1 x UART on each side.
  • 1 x SPI on each side.
  • I have not considered I2C yet.
  • 8 Analogue and/or digital pins – these are common for both sides.
  • USB pins connected to each side – not sure if I want to add an optional USB connector on the MCU as well.
  • 8 PWM signals supported by a Motor Control Timer.
  • I also added an SPI based FRAM w/32Kb for config. This is more elegant than using Internal Flash for config.

IO Modules – the list can be as long as you want:

  1. Ethernet Adapter.
  2. Wifi Adapter.
  3. Disk.
  4. Display/Keyboard Interface.
  5. RaspberryPI IO.
  6. RS232.
  7. RS485.
  8. CAN (FD, HS, FT)
  9. Analogue modules.
  10. PWM Modules.
  11. Digital IO modules.
  12. 3-P Motor
  13. DC Motor
  14. Stepper Motor
  15. Sensors.
  16. never ending story…

More to come…

 

 

 

BSA – Line Plot

Posted on by Jan

I have about a days work left and the plot is ok. The performance issue means I have limitations, but for most applications this will be more than ok. More important is that coding up the rest of the plot is about re-using components from the linear bar. I need to modify range to support time and to auto-scroll with the plot(s). I will add a simulator function allowing designers to see example data in the plot.

And then comes the more difficult issue – user controls on the plot. I will add the components separately for those who want to build their own custom plots, but I will also add a few standard ones. Stay tuned.

BSA – Real-Time Plot

Posted on by Jan

This is my first attempt on a classic line-plot in WPF and it kind-of works, but performance is optimal. I use 500 points with random values, Polyline updated 4 times a sec and 4 lines just for demo. The plot is ok’ich, but I am not impressed. Used stand alone it will be ok – neither GPU or CPU is much stressed, but add user interface to this and you get a surprice.

In this one I have added a button on top of the plot to simulate possible user interface that often is needed, and it is ok’ich due to the limited update frequency I use – 4 times a sec. But, it is again marginal – what you notice is that the button start to get slow on responding to the mouse. This did take me by surprices – I expected this to happen, but not with this limited amout of data.

The CPU is at ca 16% on my old laptop while the GPU is hardly used at all. I assume the reason why I get slow UI is because the data transfer between CPU and GPU becomes a bottleneck. The CPU usage surprices me because a raster graphics plot would have used far less CPU at this point. Don’t take me wrong – I can use this plot and UI with these limits, but my test tells me that to achieve a more performant plot I will have to dig into this. I will test this on QML and actually expect QML to be a little better on this exact issue. Performance in general is a bit better on QML than on WPF.

I have downloaded and tested several open source “high performance” plots and they have the same issue. I will test some commercial plots that claim they have solved this as well.

It is few techniques I will dig into:

  1. The CPU have to redraw the line for every update anyway on this, so drawing on a bitmap and transferring that x number of times per sec might be an option.
  2. Digging into OpenGL/DirectX API is claimed to be a solution to address the IO limit.
  3. Making a C++ component for the lines.

What I do know is that I have no issues achieving a performant oscilloscope level plot using CPU based raster graphics, I have done this with Forms, Qt, GDI+ to mention a few, so I will find a solution. For now I will wrap up this plot and wait until this becomes a priority.

Stay tuned.