Micro-Manager

Speed of PI P-721 piezo z-positioner

Classic

List

Threaded

8 messages Options

Peter Haub

Speed of PI P-721 piezo z-positioner

Dear list,

we measured the time of z-movements for an
    P-721 PIFOC^® Piezo Flexure Objective Scanner
with the simple java code:
        ...
        for (int i=0; i<nSteps; i++){
            tStart[i] = java.lang.System.nanoTime();
            try {
                app.setStagePosition(curZ + i); // 1um step size
            } catch (MMScriptException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            tEnd[i] = java.lang.System.nanoTime();
        }
        for (int i=0; i<nSteps; i++){
            IJ.log("Step " + i + " = " + Double.toString((tEnd[i]-tStart[i])/1000000.0) + " msec");
        }

The time measured are:
Step 0 = 77.361182 msec
Step 1 = 93.534456 msec
Step 2 = 93.679062 msec
Step 3 = 93.561569 msec
Step 4 = 93.626341 msec
Step 5 = 93.585068 msec
Step 6 = 93.581151 msec
Step 7 = 109.202212 msec
Step 8 = 77.994135 msec
Step 9 = 109.283854 msec

The log of the first 2 movements is:
DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) attempt to set PIZStage to 49.97951 um
DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) Device COM3 debug message: SetCommand -> MOV 1 49.9795

DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) Waiting for device PIZStage...
DBG(2011-10-18T14:46:56.003239, 4008, t:0058A118:) Device COM3 debug message: GetAnswer # retries = 5
DBG(2011-10-18T14:46:56.003239, 4008, t:0058A118:) Device COM3 debug message: GetAnswer <- ±
DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug message: GetAnswer # retries = 3
DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug message: GetAnswer <- 0
DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Finished waiting.
DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) attempt to set PIZStage to 50.97951 um
DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug message: SetCommand -> MOV 1 50.9795

DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Waiting for device PIZStage...
DBG(2011-10-18T14:46:56.081239, 4008, t:0058A118:) Device COM3 debug message: GetAnswer # retries = 4
DBG(2011-10-18T14:46:56.081239, 4008, t:0058A118:) Device COM3 debug message: GetAnswer <- ±
DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Device COM3 debug message: GetAnswer # retries = 4
DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Device COM3 debug message: GetAnswer <- 0
DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Finished waiting.
DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) attempt to set PIZStage to 51.97951 um

The time consuming steps seems to be after "Waiting for device PIZStage..." and after "Device COM3 debug message: GetAnswer <- ±".

The P-721 is connected via USB serial connector.

Our questions are:
Is this the maximum speed we can expect?
Or should it be possible to speed up the communication?

Regards,
Peter

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

Remove Ads

Karl Bellve-3

Re: Speed of PI P-721 piezo z-positioner

On Wed, Oct 19, 2011 at 1:37 AM, Peter Haub <[hidden email]> wrote:

Dear list,

Our questions are:
Is this the maximum speed we can expect?

For serial communication? I would say yes.

Just to let you know, I let the pifoc settle for 20-25ms after the command to move before any imaging occurs. This is to allow pifoc ringing to diminish. If I want to go faster, it really depends upon the step size and I then use an oscilloscope to confirm that the pifoc has settled.

Or should it be possible to speed up the communication?

Yes, by avoiding serial communication and operating systems.

Voltage, via a DAC, is the fastest way.

I was thinking of maybe designing an Arduino shield with a 16bit +-10V DAC, which would be useful in these situations. It would be much cheaper than a ITC18, which is what I use. Curious on how many people would find interest in that?

--
Cheers,

Karl Bellve

Biomedical Imaging Group

University of Massachusetts

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

Nico Stuurman-4

Re: Speed of PI P-721 piezo z-positioner

In reply to this post by Peter Haub

Hi Peter,

> we measured the time of z-movements for an
> P-721 PIFOC® Piezo Flexure Objective Scanner with the simple java code:

<left the code and logs below for reference>

Which of the three PI adapters are you using? If it is the PI_GCS, I would be interested to hear if the PI_GCS_2 makes a difference.

The logs that you included and are copied below show that a command is send to the controller, and the device adapter code then waits until it gets an acknowledgement from the controller (presumably to signal that the move finished). This is a very common theme in device control (i.e. send a command, get an answer), and many Micro-Manager device adapters implement this in the code controlling equipment.

However, a better approach is for the device adapter to send the command and then return immediately (I think that the PI_GCS_2 adapter uses that approach). This allows the UI to send out other commands as well, and in your case would reduce the wait time to something less than a microsecond. Obviously, the stage will not finish moving in that time frame. To check whether the stage stopped moving, use the Busy function (either isDeviceBusy(deviceName), or waitForDevice(deviceName) ). In the end, that should still give you the same timing, however, you could now choose to ignore the stage saying it is still moving and start you camera exposure earlier.

This latter approach is much harder to implement for device adapter authors (for instance, what if the device does not like you to send another command before it stops moving?), but it is the better approach and would make Micro-Manager operate considerably faster (for instance, if all device adapters worked like this, Micro-Manager can send out commands to all devices simultaneously and then wait for all of them to finish instead of sending out commands one by one and wait for each device in between).

> ...
> for (int i=0; i<nSteps; i++){
> tStart[i] = java.lang.System.nanoTime();
> try {
> app.setStagePosition(curZ + i); // 1um step size
> } catch (MMScriptException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> tEnd[i] = java.lang.System.nanoTime();
> }
> for (int i=0; i<nSteps; i++){
> IJ.log("Step " + i + " = " + Double.toString((tEnd[i]-tStart[i])/1000000.0) + " msec");
> }
>
> The time measured are:
> Step 0 = 77.361182 msec
> Step 1 = 93.534456 msec
> Step 2 = 93.679062 msec
> Step 3 = 93.561569 msec
> Step 4 = 93.626341 msec
> Step 5 = 93.585068 msec
> Step 6 = 93.581151 msec
> Step 7 = 109.202212 msec
> Step 8 = 77.994135 msec
> Step 9 = 109.283854 msec
>
> The log of the first 2 movements is:
> DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) attempt to set PIZStage to 49.97951 um
> DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) Device COM3 debug message: SetCommand -> MOV 1 49.9795
>
> DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) Waiting for device PIZStage...
> DBG(2011-10-18T14:46:56.003239, 4008, t:0058A118:) Device COM3 debug message: GetAnswer # retries = 5
> DBG(2011-10-18T14:46:56.003239, 4008, t:0058A118:) Device COM3 debug message: GetAnswer <- ±
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug message: GetAnswer # retries = 3
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug message: GetAnswer <- 0
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Finished waiting.
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) attempt to set PIZStage to 50.97951 um
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug message: SetCommand -> MOV 1 50.9795
>
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Waiting for device PIZStage...
> DBG(2011-10-18T14:46:56.081239, 4008, t:0058A118:) Device COM3 debug message: GetAnswer # retries = 4
> DBG(2011-10-18T14:46:56.081239, 4008, t:0058A118:) Device COM3 debug message: GetAnswer <- ±
> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Device COM3 debug message: GetAnswer # retries = 4
> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Device COM3 debug message: GetAnswer <- 0
> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Finished waiting.
> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) attempt to set PIZStage to 51.97951 um
>
> The time consuming steps seems to be after "Waiting for device PIZStage..." and after "Device COM3 debug message: GetAnswer <- ±".
>
> The P-721 is connected via USB serial connector.
>
> Our questions are:
> Is this the maximum speed we can expect?
> Or should it be possible to speed up the communication?
>
> Regards,
> Peter
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct_______________________________________________
> micro-manager-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/micro-manager-general

Nico Stuurman

Re: Speed of PI P-721 piezo z-positioner

Administrator

In reply to this post by Karl Bellve-3

On Oct 19, 2011, at 6:20 AM, Karl Bellve wrote:

> I was thinking of maybe designing an Arduino shield with a 16bit +-10V DAC, which would be useful in these situations. It would be much cheaper than a ITC18, which is what I use. Curious on how many people would find interest in that?

Ed Simmons made such boards (as well as boards with an interface to the NEOS - and possibly other - AOTF controllers). He is finalizing the design, but interested people should contact him.

Best,

Nico

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

Peter Haub

Re: Speed of PI P-721 piezo z-positioner

In reply to this post by Nico Stuurman-4

Hi Nico,

>Which of the three PI adapters are you using? If it is the PI_GCS, I would be interested to hear if the >PI_GCS_2 makes a difference.
Currently we use: PI_GCS
We will ckeck PI_GCS_2 and come back.

>However, a better approach is for the device adapter to send the command and then return immediately >(I >think that the PI_GCS_2 adapter uses that approach). This allows the UI to send out other >commands as >well, and in your case would reduce the wait time to something less than a microsecond.
That's axactly what I'm looking for.

Thanks,
Peter

Peter Haub

Re: Speed of PI P-721 piezo z-positioner

In reply to this post by Peter Haub

Today I used 2 different configurations to control the PIZStage (P-721;
Controller E-709).
Here are the times measured in the procedure described in the initial
email (see below).

<GCS2 + PIZStage from GCS2 Group>
Step 0(z=0.0) = 92.33043 msec
Step 1(z=0.0) = 93.602647 msec
Step 2(z=0.0) = 93.55324 msec
Step 3(z=0.0) = 109.174418 msec
Step 4(z=0.0) = 93.630965 msec
Step 5(z=0.0) = 93.617409 msec
Step 6(z=0.0) = 77.971527 msec
Step 7(z=0.0) = 93.571014 msec
Step 8(z=0.0) = 93.624036 msec
Step 9(z=0.0) = 93.653258 msec

With <GCS> the communication seems to be slightly slower:
Step 0(z=0.0) = 107.78441 msec
Step 1(z=0.0) = 109.115974 msec
Step 2(z=0.0) = 109.213883 msec
Step 3(z=0.0) = 109.182251 msec
Step 4(z=0.0) = 124.800416 msec
Step 5(z=0.0) = 109.195507 msec
Step 6(z=0.0) = 109.166284 msec
Step 7(z=0.0) = 109.210569 msec
Step 8(z=0.0) = 109.184058 msec
Step 9(z=0.0) = 109.224428 msec

In addition I would like to mention that the configuration of the <GCS2
+ PIZStage from GCS2 Group> always runs into an error message:
"Error in device PIZStage: Unknown Error in the device."
when I try to left the COM port settings page.
So I had to configure the device manually with known settings from a
previous configuration.

With the configuration <GCS2 + PIZStage from GCS2 Group> the autofocus
modes JAF(H&P) and JAF(T&B) ends in:
Error in device PIZStage: Error code 10107 (277b hex)

It seems as if this nice fast z device can not be used as mentioned in
the PI GCS device description
"Piezo-Z motion is used for faster step times than motor-Z - typically
about 10X faster.",
at least with a serial communication the performance will not be maxed out.

Regards,
Peter

On 19.10.2011 07:37, Peter Haub wrote:

> Dear list,
>
> we measured the time of z-movements for an
> P-721 PIFOC^® Piezo Flexure Objective Scanner
> with the simple java code:
> ...
> for (int i=0; i<nSteps; i++){
> tStart[i] = java.lang.System.nanoTime();
> try {
> app.setStagePosition(curZ + i); // 1um step size
> } catch (MMScriptException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> tEnd[i] = java.lang.System.nanoTime();
> }
> for (int i=0; i<nSteps; i++){
> IJ.log("Step " + i + " = " +
> Double.toString((tEnd[i]-tStart[i])/1000000.0) + " msec");
> }
>
> The time measured are:
> Step 0 = 77.361182 msec
> Step 1 = 93.534456 msec
> Step 2 = 93.679062 msec
> Step 3 = 93.561569 msec
> Step 4 = 93.626341 msec
> Step 5 = 93.585068 msec
> Step 6 = 93.581151 msec
> Step 7 = 109.202212 msec
> Step 8 = 77.994135 msec
> Step 9 = 109.283854 msec
>
> The log of the first 2 movements is:
> DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) attempt to set
> PIZStage to 49.97951 um
> DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) Device COM3 debug
> message: SetCommand -> MOV 1 49.9795
>
> DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) Waiting for device
> PIZStage...
> DBG(2011-10-18T14:46:56.003239, 4008, t:0058A118:) Device COM3 debug
> message: GetAnswer # retries = 5
> DBG(2011-10-18T14:46:56.003239, 4008, t:0058A118:) Device COM3 debug
> message: GetAnswer <- ±
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug
> message: GetAnswer # retries = 3
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug
> message: GetAnswer <- 0
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Finished waiting.
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) attempt to set
> PIZStage to 50.97951 um
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug
> message: SetCommand -> MOV 1 50.9795
>
> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Waiting for device
> PIZStage...
> DBG(2011-10-18T14:46:56.081239, 4008, t:0058A118:) Device COM3 debug
> message: GetAnswer # retries = 4
> DBG(2011-10-18T14:46:56.081239, 4008, t:0058A118:) Device COM3 debug
> message: GetAnswer <- ±
> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Device COM3 debug
> message: GetAnswer # retries = 4
> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Device COM3 debug
> message: GetAnswer <- 0
> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Finished waiting.
> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) attempt to set
> PIZStage to 51.97951 um
>
> The time consuming steps seems to be after "Waiting for device
> PIZStage..." and after "Device COM3 debug message: GetAnswer <- ±".
>
> The P-721 is connected via USB serial connector.
>
> Our questions are:
> Is this the maximum speed we can expect?
> Or should it be possible to speed up the communication?
>
> Regards,
> Peter
>
>
>
>

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
micro-manager-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/micro-manager-general

Steffen Rau

Re: Speed of PI P-721 piezo z-positioner

Hello Peter,

My name is Steffen Rau, I'm working for PI and have written great part of the PI_GCS and PI_GCS2 adapter. Sorry I did not notice this thread earlier.

Can you provide me a core debug log file?

What configuration do you use to connect with the E-709? Do you use the virtual COM port with an USB connection? What baud-rate? Do you use the nightly build of micro-manager?

You can send me the information and the log file to s.rau@pi.ws.

Best regards

Steffen

Peter Haub

Re: Speed of PI P-721 piezo z-positioner

In reply to this post by Peter Haub

Together with PI we could improve the communication with our PIZStage
(P-721; Controller E-709).
One important step was to connect the PIZStage directly to the USB port
(the E-709 controller has a direct USB connetion and establishes a
virtuell COM port).
The baud rate could be changed to 115200.
The communication seems to be more 'direct' in this way.
In addition PI provide a new dll for testing with a small change in
device communication. This improves the communication time as well.
PI will probably include this change into the official dll once it could
be confirmed that there will be no other conflict.

The measured times of a z movement of 1 um (as described below) are:
16 msec.

Thanks a lot to PI !

Peter

On 24.10.2011 20:22, Peter Haub wrote:

> Today I used 2 different configurations to control the PIZStage
> (P-721; Controller E-709).
> Here are the times measured in the procedure described in the initial
> email (see below).
>
> <GCS2 + PIZStage from GCS2 Group>
> Step 0(z=0.0) = 92.33043 msec
> Step 1(z=0.0) = 93.602647 msec
> Step 2(z=0.0) = 93.55324 msec
> Step 3(z=0.0) = 109.174418 msec
> Step 4(z=0.0) = 93.630965 msec
> Step 5(z=0.0) = 93.617409 msec
> Step 6(z=0.0) = 77.971527 msec
> Step 7(z=0.0) = 93.571014 msec
> Step 8(z=0.0) = 93.624036 msec
> Step 9(z=0.0) = 93.653258 msec
>
> With <GCS> the communication seems to be slightly slower:
> Step 0(z=0.0) = 107.78441 msec
> Step 1(z=0.0) = 109.115974 msec
> Step 2(z=0.0) = 109.213883 msec
> Step 3(z=0.0) = 109.182251 msec
> Step 4(z=0.0) = 124.800416 msec
> Step 5(z=0.0) = 109.195507 msec
> Step 6(z=0.0) = 109.166284 msec
> Step 7(z=0.0) = 109.210569 msec
> Step 8(z=0.0) = 109.184058 msec
> Step 9(z=0.0) = 109.224428 msec
>
> In addition I would like to mention that the configuration of the
> <GCS2 + PIZStage from GCS2 Group> always runs into an error message:
> "Error in device PIZStage: Unknown Error in the device."
> when I try to left the COM port settings page.
> So I had to configure the device manually with known settings from a
> previous configuration.
>
> With the configuration <GCS2 + PIZStage from GCS2 Group> the autofocus
> modes JAF(H&P) and JAF(T&B) ends in:
> Error in device PIZStage: Error code 10107 (277b hex)
>
> It seems as if this nice fast z device can not be used as mentioned in
> the PI GCS device description
> "Piezo-Z motion is used for faster step times than motor-Z - typically
> about 10X faster.",
> at least with a serial communication the performance will not be maxed
> out.
>
> Regards,
> Peter
>
>
> On 19.10.2011 07:37, Peter Haub wrote:
>> Dear list,
>>
>> we measured the time of z-movements for an
>> P-721 PIFOC^® Piezo Flexure Objective Scanner
>> with the simple java code:
>> ...
>> for (int i=0; i<nSteps; i++){
>> tStart[i] = java.lang.System.nanoTime();
>> try {
>> app.setStagePosition(curZ + i); // 1um step size
>> } catch (MMScriptException e) {
>> // TODO Auto-generated catch block
>> e.printStackTrace();
>> }
>> tEnd[i] = java.lang.System.nanoTime();
>> }
>> for (int i=0; i<nSteps; i++){
>> IJ.log("Step " + i + " = " +
>> Double.toString((tEnd[i]-tStart[i])/1000000.0) + " msec");
>> }
>>
>> The time measured are:
>> Step 0 = 77.361182 msec
>> Step 1 = 93.534456 msec
>> Step 2 = 93.679062 msec
>> Step 3 = 93.561569 msec
>> Step 4 = 93.626341 msec
>> Step 5 = 93.585068 msec
>> Step 6 = 93.581151 msec
>> Step 7 = 109.202212 msec
>> Step 8 = 77.994135 msec
>> Step 9 = 109.283854 msec
>>
>> The log of the first 2 movements is:
>> DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) attempt to set
>> PIZStage to 49.97951 um
>> DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) Device COM3 debug
>> message: SetCommand -> MOV 1 49.9795
>>
>> DBG(2011-10-18T14:46:55.955439, 4008, t:0058A118:) Waiting for device
>> PIZStage...
>> DBG(2011-10-18T14:46:56.003239, 4008, t:0058A118:) Device COM3 debug
>> message: GetAnswer # retries = 5
>> DBG(2011-10-18T14:46:56.003239, 4008, t:0058A118:) Device COM3 debug
>> message: GetAnswer <- ±
>> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug
>> message: GetAnswer # retries = 3
>> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug
>> message: GetAnswer <- 0
>> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Finished waiting.
>> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) attempt to set
>> PIZStage to 50.97951 um
>> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Device COM3 debug
>> message: SetCommand -> MOV 1 50.9795
>>
>> DBG(2011-10-18T14:46:56.034439, 4008, t:0058A118:) Waiting for device
>> PIZStage...
>> DBG(2011-10-18T14:46:56.081239, 4008, t:0058A118:) Device COM3 debug
>> message: GetAnswer # retries = 4
>> DBG(2011-10-18T14:46:56.081239, 4008, t:0058A118:) Device COM3 debug
>> message: GetAnswer <- ±
>> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Device COM3 debug
>> message: GetAnswer # retries = 4
>> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Device COM3 debug
>> message: GetAnswer <- 0
>> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) Finished waiting.
>> DBG(2011-10-18T14:46:56.128040, 4008, t:0058A118:) attempt to set
>> PIZStage to 51.97951 um
>>
>> The time consuming steps seems to be after "Waiting for device
>> PIZStage..." and after "Device COM3 debug message: GetAnswer <- ±".
>>
>> The P-721 is connected via USB serial connector.
>>
>> Our questions are:
>> Is this the maximum speed we can expect?
>> Or should it be possible to speed up the communication?
>>
>> Regards,
>> Peter
>>
>>
>>
>>
>