Making an Actuator- or Sensor- Control System require a little bit of software. It is many ways of doing this, but I always tend to use a pre-tested design containing of 4 main parts:
Communication is always required as we either take instructions or send data/progress to another control unit. This is usually also the largest and most complex software component needed. Many designs will implement a communication protocol and the app as just an extension to this. Myself I use an Object Dictionary.
Object Dictionary is a generic database interfacing between multiple applications using the same data. In its simplest form it is nothing but an array between data communication and sensors/actuators mapping data. A more sophisticated feature often needed is data integrity. As communication is capable of writing partly data we need a mechanism to commit or rollback so that the application only see consistent data sets. Another feature is the capability for persistent storage on selected variables or straight forward database queries.
The various user modules are Actuator(s), Sensor(s) and various other modules either using or providing data.
The last bulk of code is the infrastructure with RTOS and utilities.
The main issue here is that this design only need a map of data in the object dictionary, the right modules added and it adapts to any actuator sensor design.
Testing a new UML tool “Modelio”. This is a GPL, open source. Obviously made in and for Java. I quite like parts of the tool, but I admit that I find it a bit slow to work with yet.
They have however done some clever thinking around lines in the class diagram. Rather than having separate lines the tool allow lines for inheritance to be combined. Inheritance symbol (triangle) is a bit small for my tastse.
Saving a project is slow so I suspect the format is a database rather than XML. I find it a bit clumsy to add attributes and functions to class, but I also admit that I don’t know the tool yet.
What I don’t like with some Java applications is that you actually notice that it is written in Java – it is that slow. But, speed of the app itself is not critical, more critical is the speed of work once I know the tool. I did however like that I can edit directly in the tree at left, so speed here might be an issue of learning the tool.
This is a 5″ display and the keyboard I just ordered. I think the size is about correct. The trouble is more finding a TFT display that hide the HDMI on the back (inside) rather than demanding cables extending to the sides. I actually need a workable console for Raspberry PI that include both keyboard and display and don’t occupy to much space – interesting…
My grandparents passed away some years ago leaving a beautifully mountain farm behind. As no-one lives up there we have to leave the farm unattended for months at the time. This is a challenge in winter time as we fear the water pipes with freeze. The farm actually got internet installed so it is possible to use internet to create a remote controlled automation system.
Using Internet for anything you need to address security. Using Windows these days is not an option, so I am happy for Raspberry PI as base units. I am no web service expert, but I believe I can communicate directly between my home and the mountain farm by using a Address Lookup Service that we need to create. Basically the HMI and PLC both connect to internet and get details of whom to communicate with through a public service. Once the address is known they create a secure tunnel for communication. I will deal with security later, for now lets just assume this works and that we can use mobile devices as HMI.
The system I want to create will consist of a range of modules:
- Redundant PLC Base with mains, battery, wired and mobile internet connection as well as connection to sensors and actuators.
- Sensors for temperature, humidity, water leaks, light, movement etc.
- Camera, speakers and microphones. Actuators swithing on/off heat, opening/locking doors etc.
I use the mountain farm as design base because it present a few challenges. And I obviously want to control this using Plain.
Isolated RS485. I seldom bother with terminator resistor on RS485 because I never have errors due to this below 10 meters. Bias is a different issue as I experience problems without bias resistors on one side even on very short distances.
The main difference between RS485 and CAN is that CAN uses arbitration and is depending on better timing. RS485 is in contrary much easier to get working even with lousy solutions and cabling.
This is an isolated CAN-HS interface. ADM3053 offer a all-in-one package that cost a bit, but I decided to try it out. As for cost we are talking about 5.- USD rather than 0,5 USD.
A normal transceiver will give some protection while ADM3053 protect against much larger pulses, but it is not unlimited. Your level of protection should be adapted to your usage, and using a galvanic isolated CAN interface is basically an overkill for most hobby projects.
I need to test if I can get away with this simple circuit. The only challenge with CH340 is that it’s documentation in English is limited, so it’s a bit difficult to read up on all the pin options. But, I have seen others attempting this so will give it a try. This is CH340 as minimalist as possible with UART on one side and USB on the other.
The reason I like this is quite simple. We bought RS485 adapters for 1.- USD build on these some time back and now we simply don’t bother with anything else. They simply work to well. They always install correctly on Windows with no fuzz.
Updated the W5500 Ethernet schematics. C9 to C15 present a challenge in PCB routing since I am using 0805 packages. They are supposed to be attached close to each AVDD pin which is a challenge. Also I added the L1 ferrite bead to stop 100Mhz signals from crossing over.
But, I am still thinking that the 8.- USD breakout (below) is a tempting simplification. Particulary since the footprint will be smaller with this. I am also thinking that these breakout boards will even drop in price later.
This is the breakout board version of W5500 available for 10.- USD on AliExpress. I have a few of the more expensive ones for W5200 bought from Wiznet. Using breakout’s like this simplifies the prototyping if you assemble by hand. I also notice that Wiznet support examples for STM32F103 using CoIDE these days.
This Picture show the actual PCB With W5500. Notice the small 0201 Components. The 0805’s look massive in comparison. Usually I can use less Space adding the Electronics directly, but this is an exception. The cost of W5500 and Components are ca 3-4 USD, so 10 USD could be an acceptable trade to make it simpler.
They Reference the Board as “USR-ES1” and looking at Pictures I see a different PCB (see bottom Picture), but I assume the pinout is the same? It exposes SPI, Reset and INT, but it does not expose the PMODE pins.
This last Picture is from a different Product also marked as USR-ES1. This actually looks like it has been hand-made and not so Nice as the first one.
Lack of PMODE means that the module is wired for auto-negotiation. This can be an issue in robotics because we often have long cables and connectors of various quality. The result can be a 100Mbps that is unstable, so we need a way to force it to 10Mbps to make it stable.
This is mostly the reference schematics with minor modifications.