@john, the german patent you remember is about the optical bench
mostly, it corresponds to the english one number US 8.481,903 B2, that
should be in the archive of documentation i provided you in the folder
“Paper and Patents” - or just enter this string in google.
The module on the stage contains components to securely hold the flow
cell in place and connected to the fluidic without leakage, via spindle
motors the whole thing and hereby the flow cell surface can be aligned
to the image plane, the metal plates holding the actual flow cells are
temperature controlled via peltier elements (water-cooled). I remember
some marking on the PCB about “magnetic compensation” that surprised me
a little bit. If some documentation is neeeded i can grub out the parts
For the beginning to reverse the machine’s control i think it’s not
necessary to do start with such timeconsuming efforts like digging in
assembly code. I remember the logs are very extensive when i hunted
down a bug in one HiSeq. I expect it’s enough to sniff the serial ports
traffic while performing specific functions of the instrument (in the
end all…). Important: To do it right it will also involve to think
about the messages that will only appear if the system enters specific
conditions like overtemperatures in components. An own control software
should be planned to act like a state machine without unforseen states
left. To find undocumented things the usual approaches like extracting
strings from the binaries are helpful, i don’t expect obfuscated code
here, but i’ve seen such things while reversing lab machines.
Sniffing can both be done on the control PC or - more reliable - with a
set of TTL serial adapters connected to the FTDI chips in the machine.
All information (beside the camera link) to and from the machine is then
catched - as i like it to express with Wilhelm Tell: “He must come
through this hollow way” I must admit that in the past i had not a
system with such an amount of (virtual) serial ports. If the timing is
tricky - i used a video camera to help syncing machine’s events and
message flow in the past.
And some remark - sending commands “just to check what’s happening” can
be risky! It is not invariably the case that the commands are foolproof
if you send them on internal connections or out of context, e.g.
activating a pump while the valve is not open. The same goes for the
components in the instrument, for example the Z-stage piezo actuator can
be destroyed if driven incorrectly - e.g. when a implemented control
loop hits a resonance frequency. And i heard of VICI valve controllers
bricked by sending the command to define the number of positions present
in the valve head.