Luckily the 'MODBUS APPLICATION PROTOCOL SPECIFICATION ’ is nicely written with loads of clear examples. Reverse engineering someone else’s modbus arduino code is just getting messy. I am not sure what it is written in anyway. So it is back to basics and implementing everything in the RFC, in the most simple and generic way possible. This is where modbus being at level 7 of the OSI model makes life so much easier. Just another application…
Is that MODBUS spec somewhere public?
A code skeleton written for a modbus PLC and an atmega128 is in place. So the ideas are there but the new PCBs are on their way and the components so a PLC is going to be built and mounted in an enclosure before the 128 code is converted in sections into that for the 328. I will use a modified 9 pin D female connector on the enclosure which will not accept an rs232 cable.
My programmable load uses modbus via a 9 pin D connector, rs232 but TTL level. They warn against connecting a real rs232 cable as it would damage the interface. My experience and knowledge is rudimentary but I really think that is crap. Make connectors physically unique as if there is a way to blow something up people will find it and it will not be there fault.
Yeah, I’d be surprised if the cable would damage anything. Perhaps they’re assuming by putting a blanket ban on those cables, it’ll also prevent people from plugging in something that has a higher voltage (actual RS232) on the other end?
Completely unexciting battery management board. I only decided to produce one as the pcb costs are just over 1 USD each. Total cost with chip is about 3 USD per board . The advantage of this implementation is I am using a thermister which will be thermal paste stuck onto the lipo.
Input will be from the inductive charger which works fine. I might add a surface mount micro usb socket though that is probably best left to v2 of the board. It could also be mounted on the back which will another KiCad exercise.
Technically there is no such thing, it’s either RS232 or it’s not. The RS232 standard defines the physical interface including voltage levels. A mark (1) is transmitted as -5V to -15V while a space (0) is transmitted as +5V to +15V. Not very compatible with TTL or CMOS. These days serial ports are derived directly from pins on the SoC which is likely running at 3.3V and therefore may not be too happy with +/-15V signals on it’s pins. You may be using the same connector, maybe even the same pinout, but it’s not RS232. Technically it’s not even TTL.
Of course using a “real” RS232 cable is not going to cause any problems unless the other end is connected to a “real” RS232 port. Another thing to keep in mind with regards to a “real” RS232 cable is that sometimes they have the loopback handshaking signals, which simply shorts some of the pins together, while others are “null modem” cables meaning some wires are crossed from one end to the other. So if you use other pins on the DE-9 for other signals you might want to check your RS232 cable.
My point here is they have a D type 9 pin connector on the rear of the instrument which it would be really easy for someone to assume is RS232. Above and below this load is a PSU and DMM both of which have real RS232 interfaces on them. The instrument is supplied with comm software but no adapters. It would be very easy to make a mistake and plug in an RS232 cable from a PC.
The manual (not provided but downloadable from their website) details the precautions necessary and the part number for the special adapter sold separately. My criticism is they should have used a modified socket unable to take a normal 9 pin D type plug to prevent mistakes being made.
In my case I am using the 9pin D type as it is robust, and cheap. I am making my own cables which will be modified to fit my modified sockets. Standard RS232 will not fit, the documentation will provide details but it will not be possible to break anything anyway.
Which is pin 1?
I suspect bottom left but there is no dimple, dot or cutout. I guess the line gives it away but before I go any further being certain would be good. Thanks.
Yep. The beveled side is the other indicator.
WOW. Dead shorts from power to ground can be pigs to find. The solder mask registration was a gnats kneecap out so the solder from an 0805 resistor just bridged a nearby track that was only 90% masked. I had to crank up the microscope to full blast and look at every component in turn and it was still very difficult to spot. Just imagine if this had been a large board.
Check out the post PCB Manufacture Troubleshooting from @hedrickbt . I have had this issue too but it was on more than just one reistor.
Brilliant link. Thanks.
This is why I hate software so much. Well a few reasons. On the atmega128 dev board the RX interrupts worked fine. I could send data in and out. On the atmega328 boards (ie mine) the ISR for receipt is triggered but the data which kicked off the interrupt is blank. I cannot afford the tools that can step into an ISR and I am not too sure how to trigger a data receipt interrupt with the simulator. Or if it would be meaningful. The Data Visualiser works for monitoring data out but I cannot send it in and have the code stop on a breakpoint.
So in deep frustration I looked at the STM32 ARM cortex M4 MCU. (particularly the very nice, quick, dev board (STMicroelectronics NUCLEO-F401RE ) which is super cheap and loads of good tools. A bit more rummaging and there is a MBED 5 port of the freeModbus library. Nirvana!!
Click on API documentation. Like almost all software developers I have ever known documentation is (unless I am being really myopic) totally missing. Just the source code. How many developers have said “My code is self commentating, I need almost no comments or documentation”. OK I am ranting but I am a massive believer in documenting everything. I would rather plow 50 pages of dense but totally comprehensive explanatory text than any number of comments that only the author understood.
New boards (the final ones from a cheaper supplier) are on the way. If they are good I will get the motivation to try again or not use interrupts for data receipt which is possible but painful. I have a bread-boarded atmega328P so I could dig out the logic analyzer and have a trace on every pin. Old fashioned perhaps but why not if it helps?
The power board PCB is due soon and all the parts are in including a nice compact lipo so at least that should be finished in the next couple of days.
Yeah, this had me excited until I read the rest. No one else is utilizing this/helping document it on the web? Any chance to ask about it on their forums as well? Maybe there’s a hidden PDF somewhere?
I always think this is a good idea regardless, just to check that reality is matching what I’m seeing on screen. In my case it’s almost always overkill…but at least i know it is 
The new boards have arrived from JLC. Ten for 1/3 of the price of OSHPark, and quicker delivery to boot. They are double the thickness as well so very solid and tinned. I have an ‘improvement’ re-spin of the main PLC on order but the current boards are good enough to be put into their boxes and mounted under the rail baseboard ready for wiring. The power board has arrived so I can convert my train to battery operation. Once tested out that bit is done.
I have toyed with other MCUs for the main PLC but have decided to produce a MK2 using the atmega128. The chip is five times the price but much more versatile. More ports, inputs, USARTS, etc. I hope to use lessons learned from the train PLC to increase layout density and have 3 times the number of ports for only about 30% more board area if that. It will also have local memory for storage of downloaded code and parameters.
The RS485 interfaces have been totally reliable, as they should be. I will implement using my own packet structure and will migrate to modbus in time.
So for now a brief hiatus (and wingnut wings Sopwith kit to be built) before recommencing the rail layout build out.
No hiatus yet. Two PLCs are now in their boxes, with two more boards being built. Also a power and termination box which can take a power board (as used on the train) and two or three 18650s at 3300mAH each (or a lipo). This power box will provide 5 and 12v. This box will have an adapted male 9pin D connector (as against a female used in the PLCs) so it can plug into the last PLC in the chain. The RS485 lines will be terminated with appropriate resistors (which I will have to experiment with but ball park numbers are out there). A simple RS485 terminator plug will also be built and possibly a cable for taking power from an external supply as well.
Drilled and filed keyholes in the base of the boxes will allow them to be mounted by pushing and then sliding into place with suitably positioned screws. They can be removed and fitted without tools.
For now the power boards and PLCs are completed and the main delay is the track build which will take some time. In the mean time I have toyed with using STM MCUs which are produced in the EU by a Franco Italian Company.
These devices have several advantages over the Atmel Atmega range and I will spend the next week or so evaluating the STM32F401RE MCU. Ten very high quality PCBs are available for only $8 delivered so the cost of experimenting is minimal.
Next stage of the project is a light sequencer to do just that. LEDs in street lights and houses will be turned on in a realistic sequence by a small module driven by an I2C interface. The PLC has I2C output so this would allow me to have a network of a few small sequencers for buildings and streets in the model rail setup. The sequencer will probably have an attiny device to allow intelligent sequencing, maybe with an RTC as well.
Modbus… I am having a solar panel system installed. I see the proposed battery, controller and inverter all use RS485 and modbus. Seems quite popular.