AutomationTechnology C6 is line-profiler sensor using GenICam and GigEVision. They provide their own SDK (which I still hope to avoid for software and distribution reasons).
When I test with (lastest git main) arv-camera-test-0.8, I get an error Failed to read the current device configuration: [Width] [WidthReg] GigEVision read_memory error (invalid-access) (I can post the log with ARV_DEBUG=all:3, but it is 8MB).
When I try to access with python like
cam=Aravis.Camera.new(id)
stream=cam.create_stream(None,None)
dev=cam.get_device()
# cam.set_pixel_format_from_string('Mono8') # this fails
dev.set_string_feature_value('PixelFormat','Mono8') # also fails
the error setting PixelFormat (which does exist in the genicam XML) is:
I could also try with their SDK (they have some GUI utility) and capture with Wireshark, but if it is not necessary, only better.
BTW, is there some utility which would use camera’s genicam XML to enrich Wireshark dump so that it is more readable? What I have in mind especially is showing genicam node names instead of plain register numbers, and perhaps enumeration names.
The values output lacks a lots of features. Something wrong happens when aravis tries to access them.
Could you attach the output of: arv-tool-0.8 -d all:3 control PixelFormat=Mono8 ?
That would be a nice tool, but I fear it is not always possible to find the feature corresponding to a register access, as for example sometime the register address depends on the client software internal data which can not be deduced from the register access history.
Here you go. I suspect it might have to do with the sensor working with up to 4 regions (in different ways), and by default it only sends 2d coordinates (not the frame as captured by the sensor), but for line profilers I’ve seen till now (and also an earlier model by AT), this would be selected via PixelFormat.
Attached. I will meanwhile try wireshark dump (with the SDK and some gentl library (Stemmer?)), and perhaps pyshark will help me map registers back to genicam nodes, so that I can see what sequence they use.
I am trying with their SDK now, but no luck so far to get data. After I get it working (through their support), I will re-try with Aravis. I will report back here. Thank you for your help, Emmanuel.
As I see, there is the GevDeviceModeIsBigEndian node (true), which AutomationTechnology documents here; FLIR also has this node. MatrixVision also features this node, but mentions its deprecation, being superseded by DeviceRegistersEndianness — mentioned in “GenICam Standard Features Naming Convention” (SFNC) (can this document be used?).
Is it possible that newer devices use this node to determine endianness?
I was able to access nodes with Stemmer’s Common VisionBlox GenICam browser (not specific to AutomationTechnology), it must know about endianness from somewhere; I grepped their libCVGevServer.so for strings and GevDeviceModeIsBigEndian is in there (DeviceRegistersEndianness is not).
As a stopgap solution, there could be something like ARV_FORCE_LEGACY_REGISTER_ACCESS environment variable, which would make it possible to test (but not use long-term) the legacy access without recompilation.
As to why I did not get anything with their GUI utility — it was an unrelated bug in the canvas (on AT’s side): the data were being received but not seen on the screen.
Emmanuel, could you consider making a release in foreseeable future, so that the AT C6 exception percolates into msys packaged build? I am currently using custom build at Linux, but that is more difficult under Windows.
