Options
I can't get this stupid EVI-D100 Duet module to work
espiforenque
Posts: 3
In the interest of full disclosure, this question pertains to the practical exam. If I'm not supposed to share information about the practical exam, please delete this post. I'm just not sure where else to turn. If this were a real project, after all, this is the first place I'd look for advice.
Anyway! So far, all the channels work and provide (fake) feedback, and I can get debug information from the module by sending DEBUG-x to it. The problem I'm facing is that whenever I attempt to call a preset, I get no response, and when I manually attempt to query it...
...I invariably get this in response:
It took me forever to figure out what the heck this module was trying to say until I realized that, internally, the module must keep track of the current camera preset using a four-byte integer, and either it's rolled around backwards or this is its way of saying it doesn't know the preset. (It would've been more helpful if it had said something like CAMERAPRESET-UNKNOWN.)
I can't figure out how to rectify this situation. Is the module broken? Is it because I don't have a camera hooked up? (This is entirely plausible; there was no EVI-D100 emulator provided.) Am I sending the wrong command? Should I just ignore this and write my interface code as though the module were sending correct camera presets? (That option sucks. How am I supposed to know that it works?)
Sigh. So frustrating. This is the point at which I would've written my own code and ditched this module. I even wrote code that simulated the ACK command sent by the camera, and hooked one serial port up to the other, just to get this thing to believe that a camera was hooked up. No dice.
Anyway! So far, all the channels work and provide (fake) feedback, and I can get debug information from the module by sending DEBUG-x to it. The problem I'm facing is that whenever I attempt to call a preset, I get no response, and when I manually attempt to query it...
send_command CAMERA_MODULE, '?CAMERAPRESET';
...I invariably get this in response:
CAMERAPRESET--2147483648
It took me forever to figure out what the heck this module was trying to say until I realized that, internally, the module must keep track of the current camera preset using a four-byte integer, and either it's rolled around backwards or this is its way of saying it doesn't know the preset. (It would've been more helpful if it had said something like CAMERAPRESET-UNKNOWN.)
I can't figure out how to rectify this situation. Is the module broken? Is it because I don't have a camera hooked up? (This is entirely plausible; there was no EVI-D100 emulator provided.) Am I sending the wrong command? Should I just ignore this and write my interface code as though the module were sending correct camera presets? (That option sucks. How am I supposed to know that it works?)
Sigh. So frustrating. This is the point at which I would've written my own code and ditched this module. I even wrote code that simulated the ACK command sent by the camera, and hooked one serial port up to the other, just to get this thing to believe that a camera was hooked up. No dice.
0
Comments
My guess is that what you are trying to do would work correctly if a camera were connected. It is an unfortunate fact that many AMX modules won't work properly without feedback from an actual device. This makes implementing AMX modules difficult. Particularly, since features depending on actual communication with a live device are poorly documented, if at all.
So, try to understand the obtuse documentation provided as best you can, and write your code in accordance. Your code will be evaluated by someone who either has the camera connected, or a simulator, and it will probably be just fine. If not, they will tell you what the problem is and you'll get the chance to correct it.
In my experience, the AMX people who evaluate your code are very fine and understanding people. If there is something about your submitted code that does not pass evaluation, whoever it is who is doing the evaluation will be more than willing to explain it.
Send it.
Default value for the parameter when the module is initialized (Integer.MIN_VAL). It will retain that value until the device sends feedback indicating the current camera preset.
Yeah, that's my main complaint with this module: it doesn't check to make sure that what it's doing is working. It has never tossed up a CAMERAISNOTCONNECTED error, for instance. This is something I always try to implement when writing my own modules. I just picture the end user punching madly at the touchpanel, trying to get the stupid thing working before a super-important meeting / presentation / show, but getting nothing but the classic AMX 'joop' feedback noise with each frantic button-press - and all because one of the custodians accidentally knocked the serial connection slightly out of place while dusting the camera. If I can at least let the user know that something is wrong and they should call tech support, that's an important step towards keeping the users from hating, and subsequently avoiding, my system.
Anyway, I think I'll go ahead and just send fake information to my camera user-interface module for testing purposes. It's not something I'd like to do for a real installation, but it's the best I can do right now (short of spending a bunch of time writing my own EVI-D100 emulator, or just buying one on eBay).
Thanks again!
Have a look at channel 251. With SNAPI compliant modules it will go high when there's a device present and everything is playing nice. 252 should also flip on after all the device state information is properly synchronized.
@DHawthorne: Yeah, I've even been messing around with a "double-stage" feedback of sorts: a button will turn a bright "intermediary" color to tell the user that it was successfully pressed, and then the actual "on" color once I receive confirmation from the device. For some applications, I might even consider a red "error" color, although that's not very descriptive for the end user.
DEVICE_COMMUNICATING and DATA_INITIALISED along with power control and feedback if applicable are usually the first things I look at when validating a Duet module - especially when evaluating compatibility with an "unsupported" device. I have also started integrating the module into a test RMS Enterprise framework; while the channel feedback (251, 252) on the virtual device might be fine the intermodule listener components are not updating RMS properly.
For any Duet programmers the culprit seems to be in utilities as implemented in the ITG template: utilties.setonlinestate(state) and utilities.setinitializedstate(state). There is a conditional in the base class that prevents the update method from being called properly but the passed state parameter is returned correctly.