Best posts made by TomasKnot

Now looking at it, it is the same page and version.

Unfortunately it's just badly worded, the HMI application is only used for legacy projects. "Web Site Definitions" is a specific feature which has been completely remade, and as such are not necessary in the new integrated HMI.

If you have a look at the tutorial I have linked above it has a simple step-by-step guide for creating an HMI from scratch in the latest version.

I will get in touch with our documentation team to see if they can help you further.

You will have to create a Software Update (.swu) file containing your desired changes and/or containing the partition you want to write to the new device. There is a tutorial for doing so here, though do be careful not to overwrite the entire drive (as opposed to just the main partition) - doing so may render the device inoperable, since the boot partition is also on the drive.

The update archive can the be loaded using the latest Axon OS image. which you can download in the "Downloads -> Software -> Images" section of our knowledgebase.

I do need to stress that while we may be able to repair the device for a charge if things go wrong, performing the steps above is not supported or covered by our warranty in the case of user error.

This looks to be a driver issue with the latest Open Source OS image and L203. It should not affect L203 Mervis or Codesys. We will fix this asap.

Ahh I was assuming you are using Neuron; with the UniPi 1.1 you need to rename the inputs and outputs in the "evok.conf" configuration file; using aliases with the UniPi 1.1 is not supported as the various subdevices are fundamentally different devices. Whereas for Neuron they are, well, subdevices, which are communicated with via Modbus handles. And it is these handles which are renamed with the alias.

I can have a look if we can implement the aliases for UniPi 1.1 as well, but as of right now it's not possible. We should remove the alias-setting option for UniPi 1.1 from the web inteface.

As for the instructions, they will indeed get you the latest Master version.

Hi @roberts_lando!

It should be in /etc/network/if-eth0.conf, which is referenced from /etc/network/interfaces.

@Boy-Lenssen

I believe that @dgajic was asking about updating UniPian as opposed to Raspbian in this topic.

Anyhow - here's an answer to you. All of EVOK installations done since yesterday are broken as of right now, as a recent update of the pymodbus https://pypi.org/project/pymodbus/1.5.2/#history (~3 days ago) library broke the installation. UniPian does not have this issue.

It does not matter which version of EVOK or Raspbian you use, this is an issue with the library breaking the compatibility. We will get it fixed within today, but you will have to perform a new install afterwards.

I have only found this out now, through the issues you are having, and so thank you for the bug report.

We will have a look at figuring out a way to package the libraries with EVOK, but it's not a simple process since python libraries are distributed as source code under various licenses.

I have now released version 2.0.5c (hotfix) which should have the pymodbus library version forced to 1.4. The changes are big enough that it would not be trivial to port EVOK to the newer version, though we'll have a look at it in the future.

The specification is ModBus RTU, with a custom header. For details see: http://www.simplymodbus.ca/FAQ.htm

In practice all the Neuron TCP server does is to repack the messages from ModBus TCP to a customised ModBus RTU. The overhead associated is therefore minuscule, albeit it does exist.

It should also be noted that if you do wish to use the device directly regardless, you may have an easier time using our OSS image from downloads.unipi.technology, which uses a custom driver to get around certain problems associated with spidev. That way you will have a SYSFS interface along with a documented message structure. spidev is only used in EVOK for legacy reasons and ease of installation, both Mervis and CODESYS use the kernel driver instead.

The IO is not asynchronous in any case. The primary reason is that there is only a single communication channel back towards the primary RPi board, and so there is no convenient way to inform it of changes as they happen. The number of interrupt lines which would be required is considerably more than the number of GPIOs provided by the RPi itself. At any rate, the maximum supported polling speed of 12MHz is more than sufficient for a fast response time.

@majorcsa
Unfortunately not, the updates have broken our driver three times within the past year, and so even if it is technically easy to do with a simple build script, it's not feasible for the process to be automated in such a way.

The kernel updates by their nature change the entire API around which our driver is built, often changing things like includes, data structures, macros, function signatures etc. The process is somehow formalised by how the linking process for Linux drivers works, namely the use of a symbol table, but again the table itself changes quite a lot. Not all changes will break the module, but many have.

This is the same reason why Raspbian itself only updates to one version in ~20, and is many updates behind the latest, as it always needs to be tested (and updated) for compatibility.

Hi @mich-boxman!

You should be able to install it via our debian package repository used on Axon; instructions are available on the Evok GitHub repository: https://github.com/UniPiTechnology/evok

Hope this helps

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.