Modbus/TCP server not returning persisted values

[SteveMyres]

I set up a Modbus/TCP server (slave) to share a mix of user input values and values calculated from a combination of those user inputs and process value channel readings.  That works well.  Kudos on how easy it is to set that up!

The user inputs don't change often, so I persist them across sessions.  When starting DF again, the persisted values are displayed and used correctly in the calcs, but DF doesn't seem to want to respond with the persisted values to Modbus requests.  If the requests include only the calculated values it works OK, but if they include the persisted values, and those have not yet been set during the session, DF fails to respond to the query.  If I then set the user input values, DF will respond as expected to requests, even if they include the user values.

As a workaround, I can probably push the persisted value back into the channel on startup, but why would it be doing this in the first place?

[AzeoTech]

Persistence in channels was created more to enable one to create histories that last much longer than available RAM might allow (remember, DAQFactory was created in 2001 when RAM wasn't as available as it is now, and a 64 bit OS was not the norm).  It's called persistence because it is extended to disk and exists through restarts.  But, as a safety measure, accessing that data is a bit controlled to ensure that you don't accidentally bring in the entire persist file into memory and crash your computer.  Remember, if you just type in a channel name without any [] subsetting, you get the whole history of the channel.  This safe-guard makes it so you only get the History.  You don't get anything from the Persist unless its within the History limits.  To access extended Persist data, you have to subset specifically into that area.

Anyhow, it appears the Modbus slave has run into that safe guard.  Like you said the easiest way to deal with it is to simply copy the value over during startup.  Something like:

myChannel.addValue(myChannel[0])

 

[SteveMyres]

Well, that's what I did (actually myChannel = myChannel[0]), but I'm not following the explanation. In my case, the Persist depth is the same as the History depth, so it should fit.

But beyond that, the Modbus slave/server is only interested in the [0] member of the channel array, so as long as the History is at least one, how could it be looking at extended Persist data?   Maybe I don't understand how DF uses the persist data as well as I thought.  I always assumed that on startup, the first (History) values are preloaded from the Persist data into the History, which would certainly include myChannel[0], which is the only thing the Modbus slave cares about anyway (plus neither of our assignment statements would work if the data weren't already in myChannel[0]). So it still feels like there must be something going on I don't understand.