Devel #3
Devel #3
Conversation
Ignore error message 7 ERR if the camera is already in standby
| //----------------------------------------------------- | ||
| // | ||
| //----------------------------------------------------- | ||
| void Camera::_checkcmd() |
There was a problem hiding this comment.
The available commands were already checked in Camera::_run, so why you need this extra function?
There was a problem hiding this comment.
Commands availability has to be checked when the camera is constructed.
Otherwise other objects may get wrong capabilities.
I use the first communications with the hardware to do the check, this is in connect method which has a lock to avoid conflicts with Camera::_run.
I guess that once it is checked on camera construction it is not needed on Camera::_run method.
In my case, 1M pilatus3 does not have setroi command. If this is discovered after creating the Interface Lima thinks that hardware roi exists and crashes.
| { | ||
| DEB_MEMBER_FUNCT(); | ||
| char messages[16384]; | ||
| int aMessageSize = recv(m_socket,messages,sizeof(messages),0); |
There was a problem hiding this comment.
This will conflicts with the recv in the thread of Camera::_run.
There was a problem hiding this comment.
Camera::_checkcmd is called in Camera::connect and it has a lock that prevents from communication conflicts.
Camera::_checkcmd justs reads the answers received from Camera::_resync calls.
PD1: In fact, it may be worth to move _resync from Camera::_connect to Camera::connect.
PD2: It may also be worth to merge _resync and _checkcmd, but this depends on it's use in _run and _reinit
There was a problem hiding this comment.
Ok, It's more clear for me now...
I can merge your code as it is or with the modification you suggest, it's up to you, just tell me.
But could you remove the code in Camera::_run which check the command availability? to avoid any mistake.
Thanks again for your contribution.
P.S: You need to rebase on our master to fix conflict.
There was a problem hiding this comment.
Actually I've look a bit more deeper and I think it's safer to let the Camera::_run method do the socket reading because the _checkcmd may "eat" some other reply.
So to fix the bug you notice (Commands availability has to be checked when the camera is constructed), may I proposed you a patch (https://github.com/esrf-bliss/Lima-camera-pilatus/tree/wait_checkcmd). I can't tested it now, but the idea is to synchronize the connection with the reply of roi and setenergy command.
Tell me if it suit your need.
SEB
This pull request includes two commits.
The first fix sets the detector in ready state after stopping an acquisition.
The second fix allows to discover if setroi command is available on Camera construction.
If the command is no available the Interface do not add ROI capability