Hex string parse w/o delimiter/unique separator

[bcharles]

I have an instrument that I am able to concatenate commands when I communicate to the instrument. The instrument will then send a string of hex values back as its response. Generally there is a set of bits (06) that indicate a successful transmission which I usually use when I send a single command. Unfortunately,  the set of bits could also represent data within the response (ie: ".6").

I do know the expected length of the response for each command. Is my only option to parse subsets of the string based on the expected length or does anyone see an alternative approach?

Thanks.

Brian

[JÞB]

What is the instrument?  do you have a link to the manual?

[Mark_Yedinak]

I think you need to parse the response based on the messages you sent and the expected format for their responses. There are a variety ways of doing this. I would probably have a generic read task that passed data to a processing task. You could pass a list of message types to the processing tasks which would allow it to parse through the response data knowing what responses should be received. This task would be a basic state machine. Error handling could get tricky using this approach though if the device fails to respond to one of the commands.

[bcharles]

Inficon IC6 Thin Film deposition controller. Yes I do and have been talking to the engineers for help with communcating with it. They seem to think that I need to a basically bite off the amount of data each time. Feels brute force and doesn't allow for variability and makes the code than much more hardwired and firm.

[JÞB]

Ah yes one of those!  Too bad the engineers over there didn't think about an STX or EOM but at least you have an ACK (oh, and their parser is bad enough that they recommend automatic retries if the ACK isn't recieved)

These protocols are the most challenging to write good drivers for and I feel your pain!  I will give you a couple of pointers that Ive found useful when writing this Kind of interface.

1) remember the other end is written in C (probably poorly) but the guy on the other end defined a bunch of constants that made sense to him and wrote case statements to switch how he parsed the response.  DO the same thing with Rings and Enums- there is a list of possible commands and sub commands that each have a specific format- nested enums or rings aren't pretty but- this driver is never going to be pretty.

2)expose what you need first- you can always report "function not yet supported"  especially if for example you aren't using the ramps and step funcions- most of those functions could be done from the controller side better anyway.  KISS is the way to go.

3) bug the tech rep on the other end- eventually they'll see two things. A) their interface is obsolete and if anyone comes by knowing how to write a good protocol the customer base will dry out.  B) they are better off giving the source for the parser to a party that can easilly integrate it into an automated system and pay for the privilage.

Good luck 

[bcharles]

Great news! thanks. I see that this is not going to be one of my most enjoyable pieces of code to write.