Hello Martin,
the main problem is that the pin modes are in reversed order. By setting pinmodes_A0_A7 to 0x66600000 you enabled A7, A6 and A5, not A0, A1 and A2 as you expect.

The nonzero readings are then caused by picking up noise and other channels as mentioned by @sisktom2

Regards,
Jaroslav

Hi Stepan,
I'd go for an external C program for this purpose. The main reason is efficiency and speed of execution. REXLANG is interpreted at runtime, therefore it is slower than native binary code. Either you can use the EPC block or REST API of REXYGEN. These are the 2 most straightforward methods when it comes to external programs.

Kind regards,
Jaroslav

Hi James,

There is no direct support in REXYGEN for reading the Raspberry Pi System Information.
However I can imagine using Python script to read out the desired information (i.e. http://cagewebdev.com/raspberry-pi-showing-some-system-info-with-a-python-script/) and write it via REST API into REXYGEN algorithm.

Have a look at example 0302-03_REST_API_Python_Bash_etc, which will help you with REXYGEN REST API integration.

Hope the above is useful for you.

Cheers,
Tomas

Hi Mike,

unfortunately the REXYGEN runtime won't run on an ESP32, however you can integrate it with other REXYGEN enabled device using REST API and exchange data. Have a look at example "0302-11 ESP8266 REST API", which is originally meant for ESP8266 - I believe that the code will work also for ESP32 (with minor tweaks - don't have any ESP32 on my desk available for testing).

Let us know about your progress.

Regards, Tomas

Glad I could help!

Best regards
Jaroslav

You are right, I am sorry for my mistake. According documentation https://www.rexcontrols.cz/media/2.50.5/doc/PDF/CZECH/BRef_CZ.pdf
it seemed it was in basic installation. So it would be appropriate to modify my question: DO you consider embedding FMUCS to MODEL library in future? Thank you Stepan

Hi,
how about running Python code alongside REXYGEN and pushing the data to running task(s) via REST API of REXYGEN? This is shown in example project 0302-03 which is included in REXYGEN Studio.

Both RS-232 and CAN bus are also an option, but in that case you'll only get raw data and you'll have to parse it yourself to get useful information.

Hope this helps, let me know.

Jaroslav

Hi Eric,
thank you for sharing your work!

Jaroslav

Hello,
thanks for another contribution!

Why not use the MP block for starting the calibration procedure?

Minor note: We always recommend keeping the block name for clarity and "readability" of the algorithm. I'd go for "REXLANG_MHZ16" in this case.

Thanks again,
Jaroslav

@enovikoff Thank you, I'll see what can be done in this direction.

Jaroslav

Dobrý den,
máte pravdu. Maximální proud pro DOUT je 1A. Zátěž tedy musí být 12 ohmů a více.

S pozdravem,
Reitinger

@reitinge
Thank you
Jan

@fabio Není zač.

@mtomek Hi Michal,
I found the meaning of the errors directly in the REXduino_slave.ino code. The first number indicates the type of error and can have values:

49 - ERROR_COMMAND 50 - ERROR_PINMODE 51 - ERROR_SERIAL 52 - ERROR_ONEWIRE 53 - ERROR_I2C
The second number indicates error specification. For example for ERROR_ONEWIRE: 49 - ERROR_ONEWIRE_NOMOREDEVICES 50 - ERROR_ONEWIRE_BUSYBUS 51 - ERROR_ONEWIRE_BADCRC 52 - ERROR_ONEWIRE_DEPLETED 53 - ERROR_ONEWIRE_NOTEMPDEVICE
I agree that the errors could be mentioned more explicitly somewhere.

So in your case, the code 52 51 means bad crc error. So, for example, some noise may have appeared during data transmission.

I don't have any experience with the UniPi hub, because I'm using Monarco HAT. But as I understand to the UniPi 1-wire knowledge base, you should use the first hub port to connect the hub to your Raspberry Pi GPIO. Default GPIO pin for 1-Wire is GPIO 4. After connecting, you can read the data in REXYGEN using OwsDrv module. Please pay special attention to the note in the knowledge base:
b7515074-e8a3-460c-8a1d-58874c661791-image.png

Unfortunately, I have no idea if the UniPi hub provides ESD protection. You should check this directly from the manufacturer. If the hub doesn't have protection, I definitely wouldn't connect it directly to the Raspberry GPIO. The resistance of such a solution to the induction of unexpected voltages is negligible and it's possible that your Raspberry would get burned. In the absence of ESD protection, I would rather invest in Monarco HAT, where ESD protection is present and Monarco communicates 1-Wire over the I2C bus (documentation here), so 1-Wire is not connected directly to the processor.

Cheers,
Jan