Help formatting camera .icd command in hex (using camera file generator)

[plasmageek]

We have to write our own custom VI for a camera.One nice feature of the camera is it has it's own program for reading/setting the attributes, so I can always check my formatting or that the codes written out by Labview worked.

Now, the camera only takes hex commands. The write commands are 7-bits and are in a pretty simple format

Write command (0x57)

Address (0####)

Command (padded with zeros)

As an example, one of the commands we wrote into the .icd (and works) looks like this:

\x57\x01\x00\x00\x00\x00\x02

The exposure requires converting the time to Hex after the address. I found a mostly useful example from NI:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019YtWSAU&l=en-US

The problem I'm running into is for my placeholder. It seems like one of these two should be right, but I'm not having luck getting it to work.

\x57\x05\x58%x

\x57\x05\x58%08x

The second I verified with a small labview code (it matches what the camera setting program sends). The first assumes the camera file knows what length to send, byte order, etc. and seems less likely to be correct...Doing the send test within camera file generator gives 7 bytes for the first, and only 6 for the second (which I don't understand). Camera File Generator never receives the correct camera response, so I can't tell if it works until I open max and try it, then open the camera's setting program and check it there (which I've done a couple of times already).

We can do it through the Serial Write within our code, but I thought I'd see if anybody could help me with the formatting and get this to work. It'd be nice to be able to tinker with it in MAX.

Thanks!

[User002]

---

---

Hi, @plasmageek,

I don't have NI-IMAQ or anything, but looking at 

---

The exposure requires converting the time to Hex after the address. I found a mostly useful example from NI:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019YtWSAU&l=en-US

makes me think that it might only accept hexadecimal syntax as \xHH, not %x.

In particular, looking at your two formatting attempts,

---

\x57\x05\x58%x

\x57\x05\x58%08x

The second I verified with a small labview code (it matches what the camera setting program sends). The first assumes the camera file knows what length to send, byte order, etc. and seems less likely to be correct...Doing the send test within camera file generator gives 7 bytes for the first, and only 6 for the second (which I don't understand). Camera File Generator never receives the correct camera response, so I can't tell if it works until I open max and try it, then open the camera's setting program and check it there (which I've done a couple of times already).

---

maybe the second formatting string (\x57\x05\x58%08x) is interpreting the "%" and "x" as literal characters.

I.e. it would be sending:

• \x57 \x05 \x58 % 08 x

or, in hexidecimal,

• \x57 \x05 \x58 \x19 \x08 \x78

which would be 6 bytes.

Notes:

• "%" in unicode, hex format, is 0x19
• I think the "08" would be reporting in decimal, but 8 in hex is 0x08, so it would report the same: \x08
• "x" in unicode, hex format, is 0x78

However, I would have expected your first formatting attempt (\x57\x05\x58%x) to give 5 bytes instead of 7. If it does 5 bytes, I would try to work with that.

If you already tried it and it didn't work, then maybe the number you try to send via the %x would interpret your decimal number (500000 in the NI example) as 0x500000? Then, if it inherently knows that it is supposed to send 7 bytes, it pads the number to make 0x00500000?

You could also instead try %d. It may send the number in binary, which would mean that HEX and decimal formats are really just formats (if the number has to be converted to binary anyway). Or maybe it sends each digit as a unicode character...in which case, I don't think there's much you can do.

Or maybe all of what I'm saying is wrong. 😅

Those are my thoughts. Hopefully something helps.

-joeorbob

[plasmageek]

Hmm..you may be right about the format it requires. None of the general formats seem to work, but I did put in some generic times to be able to do tests within NI max at least. It seems strange that NI would be so strict on the hex format, but then again, I've never had to deal with binary or hex before this, so maybe there's a reason for it.

Thanks for trying to help!