I've problems with a MODBUS RTU connection to devices after a disconnect & reconnect of the RS232. The system is build up the following way:
MODBUS RTU device with A+ & B- clamps (no C = GND available, e.g. electricity meter SDM120, but problem also appears on other device types)
RS485 wires A & B
Adapter RS232 -> RS485 DA-70161 based on SP485EE chip
RS232 cable with DSUB9 connector
UART connected MAX3243 chip for RS232 with CTS/RTS
libmodbus software using /dev/ttymxc0 configured for 9600baud 8N1 (fitting to device defaults)
Linux kernel 4.4.0 embedded ARM CPU
In general this works fine, even over weeks. But once one disconnects the RS232 cable and reconnects it after some seconds (or minutes or hours), the libmodbus gets timeout-errors on every access to the MODBUS device.
This is very annoying, because it is difficult to get it back to work again. Only a lot of further disconnects of both ends of the RS232-RS485-Adapter will bring it back, after some minutes and up to 10 retries.
Any idea what could cause this problem?
Any help what to do to prevent this and immediately work after reconnect the RS232 cable?
(Yes, one possible solution is to simply let the RS232 cable be always connected. But sometime somebody need to do something and forgot about the consequences - I think this is not a realistic option)
I've got an solution, with help of mikrocontroller.net forum:
Using another RS232 → RS485 adapter DeLock 62919 and powering with +5V on the clamps by dedicated power-supply, did the job!
Now the communication comes up again, even after RS232 was un- and replugged
Related
I am trying to detect (ideally fire an interrupt) when a usb host is connected and supplies 5v. (in this design i have a separate "always on" Vsys supplied from another source).
According to the schematics in https://datasheets.raspberrypi.com/picow/pico-w-datasheet.pdf it would be possible to know this by reading the state of the WL_GPOI2 pin. Unfortunately this pin is actually located on the CYW43439 wifi chip.
The green led on the board (connected to WL_GPOI0) is trivially accessible by using the below so it seems possible to get to the GPIO on the wifi chip.
from machine import Pin
led = Pin("LED", Pin.OUT)
Is there a way of reading the WL_GPOI2 pin or otherwise finding out if a usb cable is connected?
ideal would be to fire an interrupt, but polling a status would also work.
I have a device which connects to its remote using rj45 port and 4 wire cable (a desk with adjustable height). I'm pretty sure it does not actually use an Ethernet protocol and uses sends some simple digital signals.
I want to Raspberry Pi to be able to control the device, so I was wondering if it is possible to read and dump and then send signals using Ethernet port just like I can do with any other pins? Probably the actual question here is about a way to bypass Ethernet driver in Linux OS.
This won't work. The Ethernet NIC on the RPi - just like any other NIC - can only receive Ethernet frames. Anything else needs to be connected over GPIO.
Edit: As NO-OP has reasonably pointed out, the signals may need to be made compatible with the GPIO pins - levels adjusted, maybe an opto-isolator here and there. Nothing expensive though usually. For controlling powered devices you likely need a driver or relais board - there are plenty around for the RPi.
I am developing a project using Arduino to send a message to Raspberry Pi using an APC220 Radio Communication Module.
The Raspberry Pi can't receive serial message by using USB connect to APC220. I want to know how to use APC220 in Raspberry Pi?
The APC220 has a TTL UART interface which you can connect directly to the RPi TTL UART pins on the GPIO header - you do not need the USB-Serial converter (though that should work too if it is a standard CDC/ACM device - though this suggests that there may be issues).
A note of caution however, the RPi GPIO pins use 3.3Volt logic, the APC220 datasheet is not clear on the TTL level used, but the specified supply range is 3.3 to 5.5 volts so it seems likely that it is 3.3V - best measure it to be certain. You can probably use the RPi GPIO headers's 3.3V supply pin to power the ACM220, then you will be sure to be safe. If the ACM220 level is too high, the quick-and-dirty solution is to use current limiting resistors in-line to protect the RPi (10KOhm should be enough, but don't hold me responsible; you should know what you are doing before proceeding).
The UART device on the Pi is /dev/ttyAMA0.
See here for details of serial I/O on the Pi.
22 Feb 2012 Update
The discussion here suggests that to make the TTL<->USB adapter work on Raspberry Pi, you need to disconnect the EN signal - the discussion links back to the manufacturer documentation, which gives that advice in the troubleshooting section. Since that makes the device appear as a USB serial, and you won't have to reconfigure the on-chip serial or build a connector that may be simpler.
I am trying to send/receive data over serial connection (GPIO UART pins) between a Raspberry Pi (B model, raspian wheezy) and any pc (tried a netbook and desktop, both running with win 7).
I followed all the stepts found in several tutorials like: http://codeandlife.com/2012/07/01/raspberry-pi-serial-console-with-max3232cpe/
to build a 5V to 3.3V converter. (unfortunately i can't post a pic yet)
The settings for ttyAMA0 in files 'cmdline' and 'inittab' are ok. (like described in many tutorials)
Connecting RX/TX on rpi direct works fine, so i can send text over GPIO pins and receive it. But as i connect it to a pc there is no way to read or write any data. Baudrate 9600 or 115200 doens't matter. (Hardware connection: rpi GPIO -> voltage converter -> serial USB adapter -> pc)
On pc i used Putty. On the rpi:
'echo text >> /dev/ttyAMA0' on the terminal
Putty and
minicom
but no one had success
Is there anything i missed? Could you give me some advice i could look for please.
some ideas:
Whereever i plug the usb into one of 3 available netbook USB ports the win device manager always say it's on COM3... shouldn't it change?
is there a possibility to make some measurements inside the voltage converter wiring to insure that it's not a broken component in the hardware circuit? (i have no knowlegde of it's function)
I've got usb cable plugged to my computer, which D+ and D- pins are connected to multimeter. I want to send some raw bytes to get some voltage.. is it possible at all?
I'm 99% sure that usb port I've plugged cable in is something like /dev/bus/usb/002
I know that there was possibility to do the same with LPT or RS232 ports.
RS232 and LPT are not bus ! USB devices need to be addressed in order to become reachable.
Maybe unloading and reloading usb driver that drive your usb host... or trying to make a reset on usb hub host...
For doing this kind of operation on usb port, you have to break usb kernel driver and whipe all addressing operation to address directly the chipset...
At all, due to USB concept, I'm not sure you may successfully hold some power state on outlet.
For playing with that kind of physical IO, two solution:
Install a low-cost RS-232 <-> USB adapter
or better
Buy an Arduino micro-controller for prototyping and development.
I'm nearly 100% sure that you can't send anything down your USB lead unless you actually have a device at the other end. If you still want to play with this, get a cheap memory stick, break the casing off it [not too roughly], and measure whilst doing a large file-transfer to the memory stick, or some such.
But I'm not sure your multimeter will show much, as they tend to be a bit slow, compared to USB rates.
USB uses pull-up / pull-down resistors on the data lines to detect whether or not a port is connected (1.5k pull-up to 3.3v on the device side, 15k pull-down on the host side IIRC). The exact connection depends on the device speed.
So if you connect an appropriate resistor, the host should attempt to start signalling. Because of the data-rate, you might not be able to see that on a multimeter; an oscilloscope would be more appropriate.
If you want to by-pass the normal USB protocol and just blindly send data, I think you'll need to get your hands dirty and write code to bypass the usual device drivers and access the USB hardware directly. Even then I'm not sure what's possible - the USB hardware is a lot smarter than good ol' LPT and RS232 ports, which might get in the way of doing this sort of low level stuff.