GX16 Connectors

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

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

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

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

 

BSA – Example Application

This application is done manually, but I will re-generate it from BSA later. The picture shown is a classic demo application for a 9 – Valve ValvePack. You control 27 PWM signals and 13 analogue signals in this example with 9 proportional 3-Way Valves. These are quite common in subsea systems used in the oil & gas industry and is basically a small SCADA system. I used ca 700 hours making this in Qt/QML and less than 100 hours to re-make it in C#. Once I can generate it from BSA we probably talk about 2-3 hours of work in comparison.

The demo above lack the required Modbus protocol that probably is another 100 hours since I have made it from scratch – I decided to make my own because I wanted a full protocol created in a specific way to support BSA. I have made the protocol, but need to integrate and test it before this package is operational. Modbus also need to exist as both client and server in both C++ and C# supporting ModbusRTU, ModbusTCP and Modbus over TCP with variants.

I need to point out that the comparison 700 versus 100 hours are not exact or 100% fare, but it is an indication of the difference between using Qt/QML versus C#/WPF. To re-do this from BSA will drive development a bit – so far it has forced me to add a lot of controls I will be integrating into BSA.

The actual BSA application will contain the bulding block – gauges, while the Valve Control is a control we make in BSA and re-use. Doing this is WPF is a bit more work than doing the same in Forms and BSA will be closer to Forms. But, more important is the logic behinc the controls that will be visual diagrams and part of the re-used controls as well. Working with HMI it is easy to forget the invisible magic behind the GUI that account for a lot of hours.

On C#/WPF most of the hours was on creating basic controls. That hours was probably the double in QML – QML is a bit more slow to work with since you lack a functional visual designer. But, it is the integration to the backend that made the huge difference in this case. In C# you deal with C# all the way. In Qt/QML you deal with 4 different languages that interract.

In BSA however you just draft a design consisting of design diagrams and press a button to run the system. It should be very easy and very fast, but I am not there yet…

BSA – New Gauge

Just playing around with a Torque Tool Gauge. Bit work in progress, but using a wide band as needle rather than a classic needle and due to how my gauges are build up I can easely get them adapted to various stiles. This provides 4 gauges at the space of one – a bit work in progress – playing with ideas.

I made a huge amount of components in BSA, but decided that I needed the components as a stand-alone library and be using them manually in C# before I let BSA generate code and use them in applications. Building a Gauge library is fun.

PnP with Tank Belts

I finally got the two tank belts designed and added to the frame – so will get around to mount the plates and wire the machine. The tank belt at right hang a little so I will mount a holder to lift it up a bit, but otherwise I am good to go. My current “lab” is an old bed-room, so I need to clear the proper lab in the basement again before I start designing the cabinet for the machine.

I find designing with FreeCAD very easy once I got into it – very funny to design and print your own components. The picture don’t show the holders very well, but it is basically just boxes with screw holes ready printed using PETG plastic.

PnP – Head/FreeCAD

Finally got around to design holders for my Nema8 Nozzle head + I added a damper between the Nema17 and the head to reduce noise. I need to design tank-belt holders and I can start assembling pneumatic tubes and control system as I should have all parts by now.

I used FreeCAD to design these brackets. FreeCAD works, but it is a lot of bugs so you need some patience to use that in it’s current stage (version 0.20.2) – but, I am looking forward to new versions of FreeCAD + I need to learn more about it.

One of the things I want to do is to redesign the PnP Head completely. I work with Robotics as a profession and while this design is working I also see a lot of potential for mechanical improvements. As mentioned before I want to achieve 0201 quality and to do so I need to improve the mechanical accuracy/stability of the design. The white components above is PLA, while the black is PETG – a stronger type of plastic – but in the next design I want to avoid plastic on critical parts that will wear with movements. This is a machine with moving parts – it need to move fast and with some strength. The plastic design will work fine for a short period before it starts to wear out and not to mention that it will need constant adjustments. But, this is things you learn as you build one of these.

I also want a head with 4-8 nozzle tips on + I am very sceptical to the belt driven mechanism above – I suspect it will strugle with changing nozzle tips because you need some strength to click the on/off, but lets see. I will upload the changes I do to this machine, but contact me if you want them now.

I did notice that someone had dropped the adapter (in white) on top and made a non-turnable adapter – I will advice against that – that is 40.- USD that you do not want to save as the Nema8 will twist the pneumatic tubes and cause them to wear out fast.

Also remember that the z-gantry needs oiling from time to time.

The drawing above illustrate the current frame design with 4 x 2020 aluminum profiles (V type). I considered going up to 3030 or 2040 etc, but I do not have an issue with the strength of the profiles – I do hoverer have an issue with the entire frame moving a bit. So what I want to do is to double the width of the frame as follows:

This will increase the Y gantry to 1200 mm and stabilize the frame at the same time. To do so I only need to buy 3 x 2020 profiles that is 1200 mm long + 1 extra 600mm profile. I think this will do more for stability than adding larger profiles. Using the extra sis is an issue because I seldom need feeders – as most hobbyists I use strips and components in trays – I need the extra space to put this on and this is a low cost and very effective modification I think.