Hi @romainletendart,
the serial number is available in the hostname of the PLC, which is set by the unipicheck service.
The serial number is unique per model, e.g Neuron S103, Neuron M103 and Axon L505 can have serial number 10.
Best regards,
Martin
Hello @HPC,
I am not sure if I understand the problem. Can you please specify what is connected to what on via which protocol / interface?
Thank you and have a nice day,
Martin
Hello @wzp, we don't have such thing, but you can find STEP models or CAD drawings for our products in the download section: https://kb.unipi.technology/en:files:products:00-start
Best regards,
Martin
Hi @lukas009,
it is the same issue. We will release Bullseye OS images once the support for all products is done. Looks like it could be next month.
Best regards,
Martin
Hi @knebb,
we are currently working on the Bullseye packages for the Unipi PLCs, but some important are still missing. The official release from our side will be after the official release of the RaspberryPI OS.
Best regards,
Martin
Hi @knebb,
you have verified, that the HW is working and returns correct value via standard tool. Checking and fixing your code is unfortunately beyond the scope of the free support.
Thank you for understanding and have a nice day,
Martin
Hi @knebb,
the firmware has been updated on our Knowledge Base as well: https://kb.unipi.technology/en:files:products:05-sensors:iaq
Martin
Hi @knebb,
yes, the firmware is indeed outdated. My colleague is going to fix this as soon as he gets back from holiday.
Thank you for your patience and have a nice day,
Martin
Hi @knebb,
here's a working mbpoll example reading a temperature:
root@mkudlacek:~# mbpoll 192.168.218.249 -a 1 -0 -1 -r 0 -c 2 -t 3:hex
mbpoll 1.4-25 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.
Protocol configuration: Modbus TCP
Slave configuration...: address = [1]
start reference = 0, count = 2
Communication.........: 192.168.218.249, port 502, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, input register table
-- Polling slave 1...
[0]: 0x41AD
[1]: 0x05FD
The problem is probably in the slave address. You probably use "0" (modbus_set_slave(modbus, 0)), but it is "1".
Best regards,
Martin
@knebb Try running it on lower voltage, or put another resistor in series and do the recalculation in the software.
Martin
Hi @knebb,
can you please post the C code?
Thank you and have a nice day,
Martin
Hi @knebb,
typically it doesn't pose any problem. But be aware, that when the sensor malfunctions and creates a short circuit, the 24V will apear across the AI terminals. The AI has protection for voltages larger that 15V, which will probably get damage.
Best regards,
Martin
Hello @marioverhaeg,
I moved the discussion to separate thread. Can you please post:
dpkg -l | egrep "raspberrypi|evok|unipi|python"Thank you and have a nice day,
Martin
Hi @Martijn-Hemeryck,
the article comes from the era when the resistors hasn't been present. But you can still use it now.
The Mervis has ability to act as a Modbus master (client) and Modbus slave (server). More on that can be found in our KB: https://kb.unipi.technology/en:sw:01-mervis:setting-modbus-server-hidden
The DIP switch is for engaging the terminator - a 120ohm resistor between RS485-A and RS485-B. The biasing resistors are two - one connects the 5V to RS485-A and the second connects RS485-B to the ground. Both biasing resistors are fixed and cannot be unplugged neither by HW DIP switch, nor SW configuration
Hi @Martijn-Hemeryck,
it is unclear for me what you have configured on the "other" side. On one side, you are using mbpoll, which is correct - it acts as a Modbus master. On the "other" side, there has to be some software running, which will act as a ModbusRTU slave device.
As I know you use Evok, then the problem most probably lies directly there - the Evok doesn't (and cannot as of now) act as a Modbus slave. Only as a Modbus master.
It is a bit unusual setup, but pyModbus is able to act both as a master and slave. Be aware of the limitation of the RS485 bus as it can have only one master - one initiator of the communication.
And another caveat. Our RS485 have so-called biasing resistors. Those stabilize the bus when no device is communicating otherwise the lines would be just dangling in the air susceptible to pick of EMI noise. From a certain batch of PLC (ca 2 years ago) we have started to add these resistors.
The downside of this permanent biasing resistors is, that they should be present only once on the same bus. And since both PLC have them, the direct communication over RS485 doesn't have to work in some cases because of that. Luckily enough, the RS485 allows all sorts of unusual stuff hapening (and generating) so it might work for you.
Hope that sheds more light on the matter.
Martin
Hi @tja,
this is not planned, nor it makes sense from the architecture point of view. The SysFS endpoints are generated from the Unipi kernel module, which is aware of the HW it is running on, but not aware of any peripheral devices.
The only way right now is the Evok, or you can directly poll the devices over ModbusRTU. We have some internal discussion from time to time about adding support for extensions to our ModbusTCP service. So far, no work has been done on that part.
Best regards,
Martin
Hi @mglowinski,
unfortunately no, the EVOK is not keeping any historic events.
Best regards,
Martin
Hi @honza-muller,
yes, that will work as well. Arduino + MAX485 is tried and true. Just be aware, that the Unipi 1.1 doesn't have RS485, only Neuron / Patron / Gate.
Hi @Jell-IT,
these sensors are not suitable for direct connecting to our PLCs. Our analog inputs cannot measure AC.
Best regards,
Martin
Hello @sknobloch,
accessing the Unipi Extensions over ModbusTCP is not possible at the moment, although we are thinking about it.
You need to access the devices via ModbusRTU over the corresponding serial device. Here you can find the mapping of the physical RS485 ports: https://kb.unipi.technology/en:hw:02-neuron:portmap
Best regards,
Martin