Topics created by knebb

Hi everybody,

It has been fixed with a new version of the unipi-kernel-modules package.
At the same time, we increased the output testing of packages.

Best regards,
Antonin

@knebb, I have been successful with my Axon device couple months ago.

Here is my /etc/apt/sources.list.d/unipi.list:

deb https://repo.unipi.technology/debian bullseye main

These are the steps I followed:

sudo apt update sudo apt upgrade sudo apt full-upgrade

I didn't remove any packages after full-upgrade and simply rebooted with a backup in place. After restart, I removed all obsolete packages but those which had unipi or axon in name (see later).

Currently, I'm still using the kernel from Buster because the kernel packages in Bullseye appear to be broken. If I understand correctly, we should be able to use unipi-kernel-modules-dkms with the normal Debian kernel. Unfortunately, it currently has broken dependencies, namely the unavailable unipi-kernel-headers and unipi-os-configurator-data.

Here is the list of obsolete Buster packages I have left on hold:

unipi-kernel-modules unipi-common axon-kernel-headers axon-kernel-image

Since I don't currently need a new kernel, I'm not in a rush to resolve this. However, it would be great to receive an official update.

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,

Thanks for this post, it's very helpful.

Best regards,
Antonin, Unipi

@knebb Try running it on lower voltage, or put another resistor in series and do the recalculation in the software.

Martin

@Martin-Kudláček :

Of course. Here you are. I set the registers and am measuring the AO port during the sleep() cycle.

#include "header.h" #include "vars.h" void main(int argc, char* argv[]) { modbus_t *modbusglob; union { uint16_t word[2]; uint32_t dword; float fl; } counter,direct; int n[9],mode; /********************************* Function **********************************/ void fieldbus_free(modbus_t *modbus) { if (modbus != NULL) { modbus_close(modbus); modbus_free(modbus); } } /********************************* Function **********************************/ modbus_t * fieldbus_new(void) { int err; modbus_t *modbus; char host[15]; int port; strcpy(host,"127.0.0.1"); port = 502; modbus = modbus_new_tcp(host, port); if (modbus == NULL ) { fieldbus_free(modbus); exit (55); } err = modbus_connect(modbus); if (err == -1) { fieldbus_free(modbus); modbus = NULL; exit (55); }; err=modbus_set_slave(modbus, 0); if( err == -1) { fieldbus_free(modbus); modbus = NULL; exit (60); } else { return modbus; } } /********************************* Function **********************************/ int setvoltage(float wish) { int errlvl; union { uint16_t word[2]; uint32_t dword; float fl; } wert; uint16_t ao; wert.fl=wish; errlvl=modbus_write_registers(modbusglob, 3000, 2, (&wert.word[0])); if (errlvl == -1) {printf("ERR1 modbus_write_register, %s\n",modbus_strerror(errno));} else { printf("Register set to %f\n",wert.fl);} return errlvl; } modbusglob=fieldbus_new(); mode=1; setvoltage(1.3); sleep(60); setvoltage(3.5); sleep(60); setvoltage(5.7); sleep(60); setvoltage(7.9); sleep(60); setvoltage(10.0); sleep(60); setvoltage(0); sleep(60); setvoltage(5.0); fieldbus_free(modbusglob); exit (0); }

Hi @knebb, there are two approaches and you figured out both of them:

Do the calculation and write to register 2 Write a value to the register 3000. The value has to be 32bit signed integer.

I checked the documentation and I think there is a mistake with the registers 3000, 3001 and 3002. Those should be 3000, 3002 and 3004 since the 32bit values need two consecutive registers. I will check what is in the firmware and let you know!

Best regards,
Martin

Hi @knebb,
definitely not. The DOs are NPN type (open collector). You can read more about how to read the NPN outputs with digital inputs here: https://forum.unipi.technology/topic/712/neuron-12v-digital-input/2

Best regards,
Martin

Just as an update.

I was struggling with multiple registers which are used i.e. for the AO1.1 port of my Neuron M103.

So for the AO registers 3000 and 3001 are given as "real".

I extended the above union as follows:

union { uint16_t word[2]; uint32_t dword; float fl; } counter;

And I am reading the register like this:

modbus_read_registers(modbusglob, 3000, 2, &counter.word[0]);

It reads 2 registers starting at 3000 and writes the result in the word array where it is automatically converted to "float" by the union structure.

Works fine!

/KNEBB

@knebb said in Need Some sort of Jumpstart:

it writes the state as 0 or 1 into each of the uint8_t .

Or, using semantic constants, as FALSE and TRUE.

Directly using bits would be really slow and error prone (and a nightmare for language bindings).

@tomas_hora It really depends on the actual application. I needed to measure 50mm difference in water level in tight space (approx. 30mm x 30mm). So for me, mechanical solution was a no-go, since there are no such small sensors.

But for @knebb's purpose, some set of float switches (at the bottom, 1/4, 1/2, 3/4 and at the top) could be easy and affordable solution. I would connect them to a resistor ladder and 10V power supply thus converting the 5 states into evenly spreaded 0-10V which can be directly measured by UniPi's AI input. This could be better than occupying 5 DI inputs, if the number of DI's is also an issue.

Ah, well. No I am absolutely fine with this.

My Cacti monitors the system every 5 minutes. So no need for faster- I am fine with a minute.

Thanks again!

Oh, and it is working stable. Now running for nearly 2days without a reboot.

Unfortunately the timing is too quick to be done by anything but a direct line to the CPU (Raspberry Pi/Arduino GPIOs are such a line to the CPU, which is why it works at all). As such it's not possible to use with Neuron or UniPi 1.1 out of the box. With some warranty-voiding modifications it may be possible to connect the device to an unused RPi GPIO, but I cannot recommend this action unless you are fully comfortable taking the risk and voiding the warranty. I also cannot provide instructions on doing so.

I'd rather send it directly, it's only in source code on git and compiling it is not trivial.

You should have the link in your messages now.

@knebb said in Digital in - Voltage?:

rol input has max 10V. If I change Resistor doesn't it change the voltage?

If the control input can survive max 10V, then you need to use 10V zener diode (ZD1). The resistor only limits the current to the ZD and DO, the value has to be calculated by you.

@knebb Instead of GPIOs, Neurons use other CPUs connected to SPI which take care of I/Os (https://www.unipi.technology/upload/produkty/neuron technologický popis/NeuronExplanation%402x.png). If you need PWM, then it can be enabled for Digital Outputs (currently only 4 at each Neuron model).

The easies way to set this up in C is to use the SysFS acces to I/Os which is available in the latest Opensource beta release of image, documentation available here: http://git.unipi.technology:3000/UniPi/neuron-kernel/src/master/docs/sysfs-platform-unipi.txt

Or you can always use Evok or Modbus TCP whichever suits you best.

Hi @knebb.

We use a modified kernel. You can use the commands

apt-mark hold raspberrypi-bootloader apt-mark hold python-tornado apt-mark hold raspberrypi-kernel

to prevent it being broken (also true for the Tornado webserver).

As a side note you should generally not do apt-get upgrade regularly on a non-desktop Linux system. 90%+ servers in the world do not do so to avoid precisely such issues. The same goes with any custom software. It's really only "safe" to do on a desktop with only standard packages, and even then it can sometimes break things. This is in fact the reason why Linux keeps older versions of packages in the repositories in the first place.

We plan to release packages, but all the above will still apply, functionally the differences will be
a) possibility to update UniPi software via apt
b) not needing to use the above commands manually (they will be instead done by the packages during installation)

You are of course welcome to compile the kernel yourself against any version which you wish, it's openly available in our repository.

Hello @knebb,
the current official way is to use Raspbian Stretch, then add our repository and install evok from it. Use the instructions on https://github.com/UniPiTechnology/evok.

Regards,
Martin