Hi Tomas, Thank you for your help. I understand how it works now, what you provided is where i wasn't sure what to do. It makes sense to me now. Cheers Mike

Hello @sadilekivan , this issue was caused by unknown bug in the hashing algorithm during the HMI build process. This will be fixed in next version of our software. Thank you for the bug report. Best regards Ondrej

Hello folks, I just wanted to confirm that reducing the "Max. requests" number to 1 allows multiple Modbus reads of the Click PLC. I agree that reading registers in groups of 4 or 8 is more elegant and will try that next. Cheers, Tom Sisk

@petrch Glad I could help Our developers already implemented the new functionality. Starting from new REXYGEN release it will behave as you expected - that Group itself will have also _Trigger flag. Good luck with your project. Regards, Tomas

Thanks Jaroslav, So using a not block would be the preferred way for making it work for cooling. Cheers Mike

@jaroslav_sobota no problem

Hi @jaroslav_sobota this is great news, thank you! I am going through the registration process now.

Thank a lot for explanation Ondrej. I will proceed accordingly. Best regards, Peter

Hi, In this case you just use spi_bufTx[0] = 0; If you wanted e.g. SPI_MODE = 2 and LSBFIRST, you would use spi_bufTx[0] = 2 | 8; In other words, the first 2 bits define mode, the 3rd bit defines CS behavior, the 4th defines LSB etc. CS signal is controlled by operating system. You can only change its behavior by the 3rd bit as mentioned above. As for the delay function, I have turned it into a separate topic. Best regards, Jaroslav

Hi Richard, there are various "simplifications", using various offsets to distinguish between the four tables of data. For Holding registers, the most typical is offset of 40000, but as you already noticed, this is no standard. Best regards, Jaroslav

An update to the above. I'm now very sure I had a bad batch of sensors, it turns out I'm not alone. Over people have seen the same thing having bought sensors from certain websites. Be careful when buying 1-Wire sensors as it seems there are cheaper, not so reliable ones flooding the market. Cheers Mike

Hi Richard, sorry, my mistake. You are right - both arrays have 11 items. But still the size need to comply with parameter n. Once you change it to 11 it should do the trick. Please, let me know. Cheers, Tomas

Hi Mike, thanks for clarification. I have no experience with that, but the Maxim MAX1721x with 1-Wire interface seems to be ideal for such a project with the Monarco HAT. Jaroslav

Thank you for update. If you encounter any strange behaviour again, please, let us know. Good luck with your project! Cheers, Tomas

Hi Scoobsalamander, glad I could help. You are right, I didn't take to count the timing. Good luck with your project! Cheers, Tomas

Hi Hubert, the issue was that Level1 in EXEC block is not connected. It is assumed that the Levels are connected one by one. I reconnected "tsdb_task" from Level2 to Level1 and it work now. See screenshot: Our developers will fix this issue. Thank you for reporting this. Regards, Tomas

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 Jaroslav, Awesome, thank you for your help. Cheers Mike

Hi Jaroslav, I will email you the documentation for the device. Cheers Mike

Hi Jaroslav, Thanks for the reply, yes this was the case. With a bit of scaling added it works fine, only with slight loss of resolution. Not enough to cause issues tough. Cheers Mike