Yes--I used to see these kinds of errors when I was directly reading from shared memory prior to using your API. But, zmShmRead is now protected by the internal call to zmShmVerify. There is a loop on the fields argument, but my only call to zmShmRead (or it's wrapped derivatives) only passes a single field.I think these errors occur when a script is still reading from shared memory that is no longer there if a cam has been shut down etc.
pcalleros--can you comment on whether you're unplugging/disabling/etc the cameras/monitors?
I haven't yet looked at all of the API calls to see if they might implicitly pass in more than one field into zmShmRead. Assuming that they don't and zmxap doesn't, then I'm really stumped as the zmShmVerify in zmShmRead should catch it. In addition, I'm always calling zmShmVerify explicitly anyway.If there is a loop it may be worth verifying the shared memory on each pass but there may be more complicated scenarios where this could occur that I haven't thought of yet.
pcalleros--are the log entries occurring continuously or sporadically? Are you able to correlate their occurance to anything that you know of (e.g., an alarm is occuring, etc.)?
One thought is that if these occurances are sporadic is that I can recall zmShmRead (or the wrapped function) after some minor delay if the return is undef or treat it as an ending event. If it is only occuring when the data gets reset (on event going idle), then this ought to be obvious by having the initial xAP VMI.AlarmEvent, optional telemetry xAP messages but no ending xAP VMI.AlarmEvent. pcarlleros--I'm guessing/hoping that you're monitoring output by a xAP viewer? Can you comment on the above?
Gregg