CD7 - plate loader interfacing via TCP-IP

Discuss macros to control the hardware functions of your ZEISS microscope
Post Reply
Sebastian Bech-Terkilsen
Posts: 3
Joined: Sun Nov 22, 2020 12:51 pm

CD7 - plate loader interfacing via TCP-IP

Post by Sebastian Bech-Terkilsen »

Hi everyone,

I am integrating a plate loader via TCP-IP in Python. I have the TCP-IP working well with tray ejection and loading etc.

I am wondering what you think are best practices when it comes to interfacing a plate loader. Ideally we have a way to always know if the tray is in the ejected position or not, is this possible? I can see that if its already ejected and i ask to eject, it throws no error but just executes and continues quickly. Would the right thing to do just to be catching a printed answer via TCP-IP?

Do you have any other tips to make sure nothing goes wrong?

Cheers
CarlZeissMicroscopy3
Posts: 180
Joined: Wed May 20, 2020 10:10 am

Re: CD7 - plate loader interfacing via TCP-IP

Post by CarlZeissMicroscopy3 »

Hello Sebastian Bech-Terkilsen,

as far as I understand your question you want to be sure that Zen blue did the steps you intended to do.

I would like to explain it like this:
If you write a macro and run it (directly in Zen blue or indirectly via TCP-Interface) then you automate Zen blue and 'simulate' steps as if they were done via clicks etc. in the GUI.
So generally speaking, you will get the very same 'error messages' while executing a macro as if you did the very same process in the GUI.

There are mainly two 'error messages':
First of all, the 'minor' things like 'stage could not reach the position' which are more 'information' than errors. They pop up as windows and may automatically go away, as e.g., the stage would go to the 'best/nearest position' possible.
Second, the 'real' errors pop usually up as windows that must be acknowledged like 'do you want to continue yes/no' or in very severe and rare cases you will get an exception message, which also needs an acknowledgment.

There is one additional error that comes from the macro, e.g. division by 0, that will throw an exception. In case of an execution via TCP the exception will be returned to to the TCP client. Quite a lot of the severe Zen exceptions are also propagated via the TCP interface.

So, in other words: If you execute a step in a macro, you can expect that this step is done correctly, and the next step will only be done when the previous step succeeded. In case of a severe error the program will ‘pause’ at the command that caused it or the macro will be stopped in very severe cases.

If you want to be ‘very sure’ you can make a print after each line of code so that the client always knows what has been already executed or will be executed as next step. In addition, you can use try/except of Python to react on severe cases within the macro. But in ‘normal’ cases this is not needed.
Sebastian Bech-Terkilsen
Posts: 3
Joined: Sun Nov 22, 2020 12:51 pm

Re: CD7 - plate loader interfacing via TCP-IP

Post by Sebastian Bech-Terkilsen »

Thank you, that does make sense! Certainly a simple way of approaching it. I did think that executing macros was the simple way. I will continue with that.
Cody Walls
Posts: 4
Joined: Fri May 05, 2023 2:25 pm

Re: CD7 - plate loader interfacing via TCP-IP

Post by Cody Walls »

I appreciate the clarity and thoroughness of your answer.
RodneyK Hrlich
Posts: 2
Joined: Wed Oct 04, 2023 5:29 am

Re: CD7 - plate loader interfacing via TCP-IP

Post by RodneyK Hrlich »

To always know where the tray is (ejected or loaded), you can implement a mechanism that monitors the status of the tray loader. This can be done by periodically querying the disk loader for its current status using appropriate commands over TCP/IP. By receiving and analyzing responses, you can determine whether the tray has been ejected or loaded. Checking status in Geometry Dash World regularly allows you to maintain accurate information about tray positions.
Post Reply