aravis
aravis copied to clipboard
AravisProject
Fixed #627: _send_cmd_and_receive_ack refactor
Hi,
I'm not conviced by your patch. If we receive an error packet that matches the command and the packet id, there is no reason to retry, except may be if the error is ARV_GVCP_ERROR_BUSY (but in this case, we should receive a pending ack instead).
In your example, the error code is bad-alignment. Why would the command become sucessful after a retry ?
In your example, the error code is bad-alignment. Why would the command become sucessful after a retry ?
This is the situation that we are getting now. Although the first attempt fails with bad-alignment error, it works the second time (as you can see on error log).
We are getting this error randomly on different cameras (we have 16 cameras connected) and everything seems to be ok after review all network configuration params. We only have problems (sometimes) during camera connection, everything is ok on runtime while getting images.
Any suggestion or idea?
we have 16 cameras connected
Same or different cameras ? Could you tell the manufacturer and model you are using ?
we have 16 cameras connected
Same or different cameras ? Could you tell the manufacturer and model you are using ?
Same cameras, SONY XCG 510C.
We didn't have problems with aravis 0.5.13, but we are getting this error after upgrade to 0.8.19
Same cameras, SONY XCG 510C.
I would suggest to report this issue to the manufacturer.
We didn't have problems with aravis 0.5.13, but we are getting this error after upgrade to 0.8.19
If I recall correctly, errors were not handled at all in aravis 0.5.x.
As it does not look nice to always retry on error, a proper solution to your issue would be to add a flags property to ArvGvDevice, with one flag being force-retry-on-error, and use this flag in _send_cmd_and_receive_ack.
As it does not look nice to always retry on error, a proper solution to your issue would be to add a flags property to ArvGvDevice, with one flag being force-retry-on-error, and use this flag in _send_cmd_and_receive_ack.
Yes, a new flag to choose this functionality seems to be a good solution. However, our error appears when calling to arv_camera_new, before the ArvDevice* is created. How can we add this flag?
I guess we have to introduce new functions: arv_camera_new_with_flags() and arv_open_device_with_flags().
flags being a 32 bit integer, with the first 16 bits reserved for the generic flags, and the last 16 for the protocol specific flags.
Rereading the comments, before doing any change to Aravis, I want to be sure the issue is not a camera bug.
Did you contact the manufacturer ?
Are you able to replicate the issue using the manufacturer SDK ? At least the BadAlignment error, even if the SDK is able to ignore it. If so, a wireshark capture showing the BadAlignment error would help.