@mikeyh Hi Mike,
thanks for update. Could you please try to test one Raspberry Pi with certain SD card (i.e. OS) and check with working Monarco HAT and then switch the one failing so we can say it is Monarco HAT failure afterwards?
Thanks for cooperation.
Kind Regards,
Tomas
@mikeyh Hi Mike,
you are right - however it is not necessary to use TRND blocks first (I recommend to not use it because outputs TRND:yx are already filtered according to the TRND settings).
Yes, point the HMI Component to any of TRNDV I/O - e.g. TRNDV:uVec.
Yes, the signals are extracted in the same order as they are stacked into the vector.
You can also serialise the RTOV function blocks - just set the parameters of RTOV accordingly.
Cheers,
Tomas
@scoobsalamander Yes, Kris - this is correct.
Cheers,
Tomas
Hi Kris,
thanks for this bug report. The issue is in JSON object name containing "dots". I have passed it to our developers.
Sorry for difficulties caused by this issue.
Kind Regards,
Tomas
@scoobsalamander Hi Kris,
thanks for your question. The parameter n - number of samples is related to the samples of running algorithm - therefore also related to the tick and ntickN parameters.
Kind Regards,
Tomas
@mikeyh Hi Mike,
Monarco HAT is grounded through Raspberry Pi (via 40 pin header). For complex grounding you should also ground GND output of power supply used to power Monarco HAT and Monarco HAT metal case. Could you please try it?
Cheers,
Tomas
@scoobsalamander Hi Kris,
Thank you for your comprehensive report - it is certainly a bug. I handed over all the information to our developers to fix it.
Cheers,
Tomas
Hi Kris,
sorry to hear that you are struggling with our licensing mechanism. Please, can you share you new Site ID?
Kind Regards,
Tomas
@cechurat said in Use of the 'MTM__SlaveStation_Connected' signal.:
Status shows time to next reconnect in ms
@apollo Hi Kris,
thanks for the .rio file. It says that MTM__Node0_temperature is read from Slave TS-SH-E397-01 however the signals _Connected, _Connecting and _Status refer to Slave SDSSHE39706, which is not up and running at the moment if I'm not mistaken. (and therefore Status shows time to next reconnect in ms and _Connecting is sometimes UP for a while (where while = response timeout))
Just change the auxiliary flags to MTM__TS-SH-E397-01_xxx and you should be able to see relevant information about the connection to the Slave.
Cheers,
Tomas
@mikeyh Hi Mike,
the data stored in the Archive are recognised by the Item ID. There is no "label" feature available however you can add the labels when processing the raw archive data.
Using RexArc command line utility you can add a custom header, filter the output by ID or column, etc.
For details on RexArc see https://forum.rexygen.com/topic/117/archive-export
Example of user-formatted Archive output:
Cheers,
Tomas
@apollo Hi Kris,
thanks for the log. I don't see anything suspicious.
Can you send me the .rio file of the MTM configuration?
I noticed that the _Fresh signal is 3-4s - why does it take so long to refresh the value?
Can you try to add MTM__SDSSHE39706_Status signal?
Cheers,
Tomas
Hi Mike,
It seems that there is some communication problem - hard to say more without any diagnostics.
Please, can you turn on all I/O driver diagnostic messages (REXYGEN Studio -> Target -> Configure System Log -> I/O driver messages) and share a bit of the System Log with us? (REXYGEN Studio -> Target -> Show System log -> right click -> Export Items -> All items)
Kind Regards,
Tomas
Hi Kris,
you are right about the expected behaviour of the "MTM_SlaveStation_Connected" signal.
The behaviour you are facing can mean some failure in communication. Please, can you turn on all I/O driver diagnostic messages (see screenshot) and share a bit of the System Log with us? (REXYGEN Studio -> Target -> Show System log -> right click -> Export Items -> All items)
Kind Regards,
Tomas
@mikeyh Hi Mike,
do you use grounding which was part of the Monarco HAT package? (ring terminal with screew)
Cheers,
Tomas
@apollo I understand. Just keep in mind that the Passive feature is available both at Modbus RTU and Modbus TCP.
Kind Regards,
Tomas
@apollo I see. I was not really clear. Item Addresses are all absolute - passive or active. Therefore you can have more passive items (e.g. same slave - different register range or another slave).
Please, let me know if it works for your setup which was not earlier.
One more question - what is your Modbus Slave device?
Kind Regards,
Tomas
@apollo Hi Kris, the issue is Item Address in 1st row - why is it 5754? It should be probably 1 according to the passive items.
Cheers,
Tomas
Hi Steve,
thank you for sharing the bug report and workaround. There is already completely new version of the REXYGEN Studio under Alpha testing which won't include this issue.
Thank you for patience. We can include you in Beta testing program if you want - just let me know.
Kind Regards,
Tomas