here both:
the test flow with correct:
and the other flow
Your function is dropping one value. Show me the function code.
@Becker I think you have seen it can work for you. Continue playing - you'll get it.
function after modbus flex getter:
function before modbus flex getter:
there is no other function 
the buffer parser is 100% the same!
I dont understand why you are trying to integrate the correct solution in the old flow ..
lets concentrate on the NEW correct flow .. and lets pick a value that doesnt need light .. like the temperature of the device?! you need this value ?
the old flow works fine, just 2 values have to be adjusted (var with negative, and U DC2 when it goes over 655V).
And how do you plan of fixing it in the old flow when you have 20 different requests in flex getter and 20 different replies passing from a join node that merges the messages and the buffer cannot differentiate, this way, which is which to convert correctly ?
even if you do get a message out of the join node after 20 messages most probably the responseBuffer.buffer will be a 'leftover' from the last request in the queue?! its a mess
I have to open a new thread, this has been a little bit long.
Steve will help me to make a new modbus query.
this ?
well .. i feel bad suggesting this because it is NOT the correct solution .. but
you could do separate requests for only the two values you mentioned above that truly need to be 32bit and need to processed with buffer parser and then send them to your dashboard
that means un-linking those two from making a modbus request and most probably you need to change your first join node to 18 messages
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
