search

BiancoRoyal / node-red-contrib-modbus

maintained by PLUS for Node-RED - https://plus4nodered.com
https://www.npmjs.com/package/node-red-contrib-modbus
BSD 3-Clause "New" or "Revised" License
306 stars 112 forks source link

Error being thrown repeatedly: 'FSM Not Ready To Read' #44

Closed MonkeyDo closed 7 years ago

MonkeyDo commented 7 years ago

Hello,

In my node-red project, I am relying on the state of a modbus client node to raise a disconnection alert. The modbus client node gets set to an error state very briefly but repeatedly. The error thrown is FSM Not Ready To Read, throw at this line

I did some debugging, and when that error is thrown the state of the FSM is 'READING' It is indeed not one of the allowed states: modbus.core.client.messagesAllowedStates = ['ACTIVATED', 'QUEUEING', 'EMPTY']

Is that the expected behavior?

Now, for more details: I am using node-red-contrib-modbus@1.1.0 I am polling 3 modbus programmable logic controllers at an interval of 1 second. I have only had this problem while running my node-red project inside a docker container; I suspect I may have some added latency while reading because of that, but after some testing have found the latency perfectly acceptable (in the order of a few milliseconds). The same project running outside of a container does not throw those errors.

If the error being thrown is the expected behaviour, I'll have to look at either not relying on the state of the node, or trying to see what could cause a delay with the communication with the physical modbus element.

biancode commented 7 years ago

a) Yes, that is exactly the expected behavior. You try to read, and that is not possible on request. b) Your requests to write comes to fast. Is it an "Inject at start" problem? You could wait/delay or ignore the FSM is not ready while requesting. That is not a bigger problem.

sirajmustafa commented 7 years ago

I am trying to poll 2 Modbus Slaves (tried both Serial and TCP) with a poll rate of 100ms. Many scans gets missed when I poll both Slaves even with an alternating trigger to avoid both being polled simultaneously. When I disconnect one Slave then the scan are perfect. Any idea if this is a Modbus Node limitation or NodeJS itself is getting slow when too many polls happen. I perhaps tried separating both Modbus Readers on separate flows, connections even changed the gateway so each slave can connect on different modes (one is Serial and other in TCP). Any help is highly appreciated.

moldino commented 7 years ago

Hi! I'm using the modbus-getter to get a status register from a machine at the factory floor. I get the "FSM Not Ready To Read" at the Modbus-Getter over night when the modbus client is offline (mains turned off). Is there some easy way to get the reader to restart/reset and wait for the modbus client to get back online again (next day). (I hade the same issue when I tried to use OPC-UA to do the same thing.) Regards //Magnus

biancode commented 7 years ago

@sirajmustafa I think you're too fast in communication with the gateway or in parallel, check the queues with the Queue Node and try to poll at the best time as your gateway accept all requests without growing in the queue. You should use only one physical connection to start testing with the gateway. With that, we are saving to get channeling by the gateway for the slaves. You can send an example flow via E-Mail.

biancode commented 7 years ago

@moldino is it Serial or TCP? The normal behavior is a reconnect behavior by the settings of times from the client. If it doesn't work, then there is a connection which opens or doesn't close as expected. Please send some detailed log for that!

sirajmustafa commented 7 years ago

Thanks @biancode for your reply. Yes the poll speed for my application required high speed communications. I finally had to drop Modbus and use serial communication node and write my own protocol for Advantech ADAM 40xx Modules and progressed further. It was interesting to develop and was always thinking the challenges you must have been going through to do the same with Modbus.

Will send you the example flow later by email of the Modbus version I was using. Thanks again.

apanasara commented 6 years ago

Please help to resolve error msg 'FSM Reset On State INIT' error

biancode commented 6 years ago

@apanasara Hi, I need some logs please or is it done

apanasara commented 6 years ago

@biancode, thanks for prompt response... Log is as shown in right panel...

I tried, modbus read, modbus getter, modbus flex getter etc... But same error is displayed...

Used manufacturer's software & modbus scan software, they are fetching value from device...

Somavaram commented 6 years ago

@apanasara Hi, Even I am facing the same problem please let me know if you have found some solution for this. Thank you!

apanasara commented 6 years ago

@Somavaram : Hi, Issue was resolved... Manufacturer was using 2 register for sending value of 1 parameter, Hence I doubled the the variable size uint_32/ float_32. Then value was received correctly....

Try, if you will not be able to receive values, then I will send my code...

deepu2 commented 4 years ago

@Somavaram : Hi, Issue was resolved... Manufacturer was using 2 register for sending value of 1 parameter, Hence I doubled the the variable size uint_32/ float_32. Then value was received correctly....

Try, if you will not be able to receive values, then I will send my code...

Hi, I'm having the same issue, what do you mean by uint_32/float_32?

apanasara commented 4 years ago

@deepu2 : please post your code where you are receiving the value from modbus & vendor catalog stating regarding register address

example if your parameter(p) requires two register r1 & r2 to get value binary received r1 = 001...01 r2 = 110...01 resultant float p = BinaryToFloat(r1 r2) p = BinaryToFloat(001...01 110...01)

Somavaram commented 4 years ago

Hi Deepu,

It's been a long time I have worked with NodeRED. Sorry that I couldn't help you.

On Sun, Jan 5, 2020 at 12:57 AM He notifications@github.com wrote:

@deepu2 https://github.com/deepu2 : please post your code where you are receiving the value from modbus & vendor catalog stating regarding register address

example if your parameter(p) requires two register r1 & r2 to get value binary received r1 = 001...01 r2 = 110...01 resultant float p = BinaryToFloat(r1 r2) p = BinaryToFloat(001...01 110...01)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/BiancoRoyal/node-red-contrib-modbus/issues/44?email_source=notifications&email_token=AHFYRT57KB4QYINBI67GGULQ4EO5FA5CNFSM4DPOAZB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIDC5SQ#issuecomment-570830538, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFYRT76DAJOF5BIIYH4BRLQ4EO5FANCNFSM4DPOAZBQ .

tjunussov commented 4 years ago

Today with node-red-contrib-modbus@5.13.2 same issue happen, I use Modbus TCP with HTTP_IN->FLEX-READ-HTTP->RESPONSE Nodes, and If made partial redeploy, after that Flex-Read throws "Not Ready to Read" and now I have logs like

2020-05-31T23:52:01.997Z contribModbus:queue:core queue serial unlock command node Modbus Flex Server

2020-05-31T23:52:05.426Z contribModbus:queue:core sequential de-queue command

2020-05-31T23:52:05.431Z contribModbus:queue:core queue serial unlock command node Modbus Flex Server

2020-05-31T23:52:35.492Z contribModbus:queue:core sequential de-queue command

2020-05-31T23:52:35.502Z contribModbus:queue:core queue serial unlock command node bibit modbus tcp client

2020-05-31T23:53:35.494Z contribModbus:queue:core sequential de-queue command

2020-05-31T23:53:35.503Z contribModbus:queue:core queue serial unlock command node bibit modbus tcp client

2020-05-31T23:54:02.107Z contribModbus:queue:core sequential de-queue command

2020-05-31T23:54:02.113Z contribModbus:queue:core queue serial unlock command node Modbus Flex Server

2020-05-31T23:54:35.494Z contribModbus:queue:core sequential de-queue command

2020-05-31T23:54:35.501Z contribModbus:queue:core queue serial unlock command node bibit modbus tcp client

2020-05-31T23:55:35.493Z contribModbus:queue:core sequential de-queue command

2020-05-31T23:55:35.500Z contribModbus:queue:core queue serial unlock command node bibit modbus tcp client

2020-05-31T23:56:35.494Z contribModbus:queue:core sequential de-queue command

2020-05-31T23:56:35.503Z contribModbus:queue:core queue serial unlock command node bibit modbus tcp client

Is it normal behavoir ?

To be sure, I didnt quite get meaning of Not Ready to Read, as you mentioned above I think it applicable only to write, but not read, and I dont have any writing operations, just reading

biancode commented 4 years ago

@tjunussov you get more information since 5.12.x+ - It sounds like you do to much at a moment or it is not configured well - hard to say without any flow. This is support for a new version and should be a new issue, please.