Hi Friends,
TL:DR - The ascii character 160 (non-blocking space) works fine in well selection strings in .esc files but not in .gwl files.
I’m writing some python code that will generate worklists for a particular protocol we are wanting to automate. The plate layouts change from run to run and I thought it would be easiest to set it up as a worklist. And in order to be efficient with my tips I am using the advanced aspirate and dispense commands.
These commands take a well selection string that is composed of ascii characters with each representing 7 wells on the plate. These are assembled as a bitfield and then the arbitrary value 48 is added to make sure that they are all printable characters.
However this puts some of the possible values above 127 which are also not regular ascii characters. In my particular issue I am trying to aspirate from the second column of a 4 row by 6 column plate. When I do this selection string I have a binary 01110000 which is 112. I then add 48 and this gives 160. That as an ascii character is a non-blocking space character. So the string would look like “0604 100” where that space is actually NBSP (ascii 160).
I opened the file up in binary mode to look and see what value it had in that position and this is what I see.
00000410 31 2C 22 30 36 30 34 A0 31 30 30 22 2C 30 2C 30 1,“0604 100”,0,0
That A0h is the character in question. Whenever that character is there I get this error when I try to execute the worklist “Cannot evaluate expression 0604 100”.
I decided to try to see what happens if I let Tecan software write the same step so I created a protocol that included the same step. I then opened the .esc file and to my surprise found the same character working just fine in the well selection string there.
(Showing 2 lines because the string wraps. The offending char is first char in second line)
00000840 30 2C 30 2C 31 36 2C 30 2C 31 2C 22 30 36 30 34 0,0,16,0,1,“0604
00000850 A0 31 30 30 22 2C 30 2C 30 29 3B 0D 0A 41 73 70 100”,0,0);…Asp
So it is still using A0h and here it is working just fine and EVOware has no problem parsing the string.
I’ve checked the encoding. Both files are using ansi encoding and the same \r\n windows style line endings.
I’m sort of up against a brick wall here. 160 is one of the possible values for a character in that well selection string, but for some reason EVOware won’t parse that for some reason.
Does anyone have any ideas where to go next?