That does look quite good! The CPU will indeed be high with direct polling unfortunately, particularly with Python. We are hoping to implement an interrupt structure to remove the vast majority of the load, though it will have considerably higher latency due to various extra overhead the interrupts will introduce, so it is a tradeoff. You may also get slightly lower overhead with libgpiod/libiio, but the same problem will remain.

In practice we haven't designed the I/O for particularly fast reaction times, as they are primarily intended for electro-mechanical components like buttons and relays, which themselves have very considerable switching delays. That is not to say they cannot be used in that way, but it does bring some limitations with it. In particular our PLC platforms are designed to run with multi-millisecond cycles, Mervis at ~20ms and CODESYS at ~4ms.

Hi @Martijn-Hemeryck!

Apologies for the somewhat late reply, we are quite busy at the moment. I do think standard polling is the best way to go; linux GPIOs/IIOs do have support for deeper interrupts, but we do not currently implement these. Some form of polling is then unfortunately necessary.

It should be noted that the SYSFS interface uses the regmap linux subsystem to create a form of read caching. This means that on one hand reads will have a considerably lower overhead than reads directly via the SPI device, but that on the other hand the sys_reading_freq property limits the practical refresh speed to 1ms - there is no need to poll any faster than ~500us, as the reads will simply hit the cache the vast majority of the time.

We do not have a dedicated library ourselves, but you may be able to use libgpiod and libiio if you prefer to use one.

I hope this helps

Hi @dominikmlkvy,

This looks like a hardware problem. Are there any visible signs of damage on the board, or perhaps an interrupted connection somewhere? It might help if you can provide photos of the device in it's current state with a sufficient resolution to examine the hardware.

If you are positive that you have not used the device in a way that is outside the intended operating parameters you can send the device for a replacement, but you may be charged some or all of the cost if the fault is due to improper use. Please contact support@unipi.technology for further help.

We keep test logs of our devices before sending them out - it would help if you could provide me with a serial number of your device so I can check it, but I don't expect that it failed testing as we perform a final check before sending each product.

I hope this helps

Hi @thiagoralves,

Apologies for the late reply, I was on sick leave for a while.

It looks like we still haven't released the image, but I'll try poking the people who take care of it a bit. The package installation should now work, however.

Hi @luc!

Yes, by directly I meant via SYSFS, apologies for not being clear. You may want to decrease the reading interval sysfs property to increase the throughput, though it may still be too slow.

It looks like EVOK is not running. Please try using:

sudo su
systemctl status evok
systemctl status unipitcp

The output should at least say what's gone wrong. I will try to replicate it locally as well, but it may take a while.

Apologies, it looks like you will have to use

apt-get install unipi-kernel-modules-dkms

instead of

apt-get install neuron-kernel

this will install the module from source, rather than using a precompiled binary.

The rest of the instructions should work fine. At any rate - we should release a new version tomorrow which should have the bug fixed.

Hi @thiagoralves!

I believe I have now identified the problem. Unfortunately the update above will likely not work (though it should not cause any harm either) - I will have to generate a new version of our kernel driver. This will take approximately 2 days; apologies for any difficulties caused.

The issue is that the secondary analog output is missing a correct error code for reading, which the primary analog outputs do have. This causes a null pointer dereference and a subsequent crash. That said - the crash occurs because the IIO kernel subsystem does not check for a null pointer value where it is permitted, which it should, so it is possible that a general kernel update (which the commands above will try to perform) may help. However a definitive fix will be creating a dummy method to pass to the subsystem, which is something we should do regardless.

Thank you for the debugging, and apologies for any problems caused. I should say that aside from reading the particular file there doesn't appear to be anything else wrong with the unit, and it should otherwise perform as expected.

Hi @thiagoralves!

The software version you have (both for firmware and kernel) is relatively old. I cannot guarantee it will fix the issue, but you should be able to update it easily by running:

sudo su
mount -o rw,remount /
echo "deb https://repo.unipi.technology/debian stretch main" >> /etc/apt/sources.list.d/unipi.list
wget https://repo.unipi.technology/debian/unipi_pub.gpg -O - | apt-key add
apt-get update
sync
reboot
----reboot occurs here----
sudo su
mount -o rw,remount /
apt-get install neuron-kernel
sync
reboot
----second reboot occurs here----
sudo su
mount -o rw,remount /
apt-get install unipi-modbus-tools
apt-get install unipi-firmware
sync
reboot

This should install the latest firmware, kernel and modbus server. Though unfortunately I really cannot say if that will fix the issue right at this very moment. I'll have a look into the code in the meanwhile, but please do see if the commands can fix the issue.

I will check the image on our download server to see if I can get it updated. If you do encounter any errors in the installation process then please do post here; the packages are tuned for a standard raspbian image, and may possibly not work properly with the older image from our server.

Hi @thiagoralves,

It looks like there is either an issue with the driver or the hardware. The driver shouldn't be doing this certainly, ideally under any circumstances - though realistically we cannot always prevent it. I'll try it locally with our own M503 - as you have used the latest image you should have both the latest firmware and driver, so there is definitely something fishy going on there! I'll have time to look at it on Monday at the earliest, but at least I can definitely say that this functionality has been tested in the past, but there have been some changes relatively recently which could have broken it.

One other thing you could do is try to run

sudo /opt/unipi-bin/fwspi -i 1

and paste the result here; it should show firmware details about the analog board. It might help us look at the test logs for the specific hardware unit and firmware version, to see if there's anything out of ordinary there. But I assume the issue will lie with a recent rewrite of the kernel driver.

Thank you again for reporting the issue, and I hope this isn't too much of a setback. And one other thing related to the SYSFS - you should set the scanning frequency higher, since all SYSFS inputs run on various multiples of it. The low initial setting is to prevent the communication bus from getting unnecessarily overcrowded when using another IDE such as Mervis or CODESYS, which sidestep it by using the /dev/neuronspi character device directly.

Edit: Another useful thing might be output from

sudo dmesg

at some point preceding the crash. This will show details about the kernel driver.