AutomationTechnology C6

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.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:

gi.repository.GLib.GError: arv-device-error-quark: [PixelFormat] [PixelFormat] [PixelFormat] [Coord3D_C16] [isCoord3DC16Available] [isCoord3DC16Available] [isComponentRange] [isComponentRange] [ComponentSelectorReg] GigEVision read_memory error (invalid-access) (14)

arv-viewer-0.8 shows this:

but also this (just a few secs later):


and will not open the camera at all.

Where to start looking into that? Anyone could help?


Please post the output of arv-tool-0.8 features and arv-tool-0.8 values.

Thank you, Emmanuel, I am attaching the files here.

at-features.txt (44.8 KB)
at-values.txt (9.4 KB)

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.

pixel-format.log (7.8 MB)

Please attach the output of arv-tool-0.8 genicam.

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.

genicam.xml (698.4 KB)

I don’t see any obvious reason aravis would not be able to access ComponentSelectorReg. It is a read/write register with a fixed address.

Could you try to enable the legacy register access behaviour by adding your camera here:

I don’t think it will change anything, but I’d prefer to try it before investigating more.

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.

Could you try to enable the legacy register access behaviour by adding your camera here

Thank you, this actually helped! I am surprised that this device needs workarounds, since
AutomationTechnology is an active member of EVMA.

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 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.

Sure. I’ll do that by the end of the week.


Aravis 0.8.30 is out.