Topics created by Vesa Kauppinen

Hi @Vesa-Kauppinen,

try apt update && apt upgrade again.
We made some adjustments due to the new Unipi Iris HW, but this should work fine now.

Best regards,
Antonin, Unipi

Hello @Vesa-Kauppinen,

this has been subject to change between Linux kernel versions - the older one

cat /sys/devices/soc0/soc_uid

comes from the original iMX kernel and has been removed by NXP in newer releases. In our kernel image, we additionally preserve it for backward compatibility.

However,

cat /sys/devices/soc0/serial_number

is a "Linux standard" provided by recent NXP kernels that we recommend using as a unique identification.

Hello @Vesa-Kauppinen,

The 'dev' field describes an object type (similarly to di or relay) so the key has to be constant regardless of the PLC series. You are right, this can be a little bit confusing - it's a piece of history ;-).

Now, we will add the new field of a family containing Patron/Neuron/Axon string.

The 'dev' field fix is a breaking change of the existing API and will be subject to change within an upcoming new Major version.

Hi @Vesa-Kauppinen,

From Unipi Patron I/O boards by:

Section 1: mbpoll -m tcp 127.0.0.1 -a 0 -0 -1 -r 1003 -p 502 Section 2: mbpoll -m tcp 127.0.0.1 -a 0 -0 -1 -r 1103 -p 502 Section 3: mbpoll -m tcp 127.0.0.1 -a 0 -0 -1 -r 1203 -p 502

And from Unipi Extension using ttyNS0 port:

mbpoll -m rtu /dev/ttyNS0 -b 19200 -P none -0 -1 -r 1003 -a 15

Best regards,
Antonin

Hi @vesa-kauppinen,
this is a soft error and you don't need to worry about it.

Martin

Hi @martin-kudláček !

Did you receive my email?

Br,
Vesa

@martin-kudláček said in Axon M505 bluetooth:

Could you please share with us your intention, so I can point you to proper solution?

Hi,

We have developed our own software for Axon. We would now like to have Bluetooth enabled.

With these instructions (http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Plus2#Bluetooth), we have not been able to do it work.

I would be very grateful if I could get specific instructions for starting Bluetooth.

Also ping @TomasKnot

/Vesa

Right - but does RX?

unipi_plc is only on the beta image, apologies

And I would try Mervis if possible. It has drivers done via a different library, and has better debugging facilities. Though if the RX light does not turn on Mervis won't be able to do much - it will just display constant timeouts.

e: More specifically no RX light means that there are no replies, TX light simply means that something is sent, regardless of whether the settings are correct or not.

Hi @vesa-kauppinen,
writing 1 to coil 1001:

mbpoll -m tcp -a 0 127.0.0.1 -t 0 -0 -r 1001 1

Writing 0:

mbpoll -m tcp -a 0 127.0.0.1 -t 0 -0 -r 1001 0

You can learn more from the quite detailed help of the mbpoll:

mbpoll -h

Regards,
Martin

@Vesa-Kauppinen This is a bit more complicated than it seems. First of all, Evok cannot guarantee any time of physical response. Secondly, there is a lot of overhead with the HTTP encapsulation. All this together with available CPU processing power at the moment of the request (actual load of CPU by other applications) can lead to a various time of reaction to the request.

From what we have tried it can take about 150ms to switch the relay when the command is called from the same RPi using curl.

If you need faster responses, you can always use the default Modbus TCP where you will get to around 10ms response time.

@devien Have you tried to implement debouncing of the DI?