AW: motor model 3 with binary commands PiCo 33 piezo CN30 controller

["Sintschuk, Michael via Tech-talk" <tech-talk at aps.anl.gov>]

Hi again,

 

the piezo is moving fine by now. My problem now is to stop it via the stop-button: how can I break the while-loop, that makes the piezo move step-by-step, when the user pushes the stop button? So far, all handling basically happens in the move-function:

 

asynStatus CN30Axis::move(double position, int relative, double baseVelocity, double slewVelocity, double acceleration)

{

    asynStatus status;

    int steps, steps2Go, moveSize;

   char command, step, raxis, rspeed, dir;

    // static const char *functionName = "CN30Axis::move";

 

    //chose the axis bit, we accept only two axes so far

    if (axisIndex_ == 1) {

        moveSize = position - axisXpos_;

        raxis = 0x00;

    } else {

        moveSize = position - axisYpos_;

        raxis = 0x40;

    }

 

    //we can choose out of 4 velocities

    if (slewVelocity == 0) rspeed = 0x00;

    else if (slewVelocity > 0 && slewVelocity <=1) rspeed =0x11;

    else if (slewVelocity > 1 && slewVelocity <=2) rspeed =0x10;

    else if (slewVelocity > 2 && slewVelocity <=3) rspeed =0x01;

    else rspeed=0x00;

 

    //direction and move size depend on the steps already done

    if (moveSize > 0) dir=0x00;

    else dir=0x08;

 

    steps2Go = abs(moveSize);

 

    setIntegerParam(pC_->motorStatusDone_, 0);

 

    while (steps2Go > 0)

    {

 

        if (steps2Go >= 100) step=0x07, steps = 100;

        else if (steps2Go >=  50) step=0x06, steps = 50;

        else if (steps2Go >=  20) step=0x05, steps = 20;

        else if (steps2Go >=  10) step=0x04, steps = 10;

        else if (steps2Go >=   5) step=0x03, steps = 5;

        else if (steps2Go >=   2) step=0x02, steps = 2;

        else if (steps2Go >=   1) step=0x01, steps = 1;

 

        command = raxis + rspeed + dir + step;

        // ex : 0x00   +  0x10   + 0x08 +   7

        // ie:  axis1    speed4  + neg  + steps

        pC_->outString_[0]=command;

        pC_->outString_[1]=0;

        pC_->writeReadController();

 

        steps2Go = steps2Go - steps;

    }

 

    if (axisIndex_ == 1) {

        axisXpos_ = position;

        setDoubleParam(pC_->motorPosition_, axisXpos_);

    } else {

        axisYpos_ = position;

        setDoubleParam(pC_->motorPosition_, axisYpos_);

    }

 

    setIntegerParam(pC_->motorStatusDone_, 1);

 

    return status;

}

 

I tried to introduce some stop_ variable but once the loop-starts it can not see changes made by the user to this variable (by pressing stop). Only after the whole move-function is finished, changes are seen. Also calling “callParamCallbacks();” inside the loop isn’t showing any effect.

I also don’t see how the poll-function could help, since it is not called during the while-loop …

 

Any suggestions how I can solve this problem?

 

Btw.: I uploaded the whole driver to github here:

motorMicos/micosApp/src/CN30Driver.cpp at master · MichaS-git/motorMicos · GitHub

 

Michael

 

Von: Sintschuk, Michael
Gesendet: Mittwoch, 7. Februar 2024 17:29
An: 'Mark Rivers' <rivers at cars.uchicago.edu>; tech-talk <tech-talk at aps.anl.gov>; 'tboegi at edom.se' <tboegi at edom.se>
Betreff: AW: motor model 3 with binary commands PiCo 33 piezo CN30 controller

 

Hi Torsten, hi Mark,

 

yes indeed, it’s not a timeout but just a delay. I could verify it by changing the move speed and the move size (the shortest move size with the fastest speed results in a ~7ms delay). Also, eom=0 returns.

 

I was just wondering because I can actually hear the individual while-loop-steps while the piezo is moving. When I move the piezo manually with the operating unit by pushing the button (while the button is pushed the piezo moves), the noise is constantly. It varies with the chosen speed, but it is not choppy.

Btw, I have connected the controller with RS232 via a NPort Serial Device Server. So, the communication goes from TCP/IP to serial and back. But I guess this is not the bottleneck.

 

However, thank you both for the help!

 

Regards

Michael

 

Von: Mark Rivers <rivers at cars.uchicago.edu>
Gesendet: Freitag, 2. Februar 2024 18:37
An: Sintschuk, Michael <michael.sintschuk at bam.de>; tech-talk <tech-talk at aps.anl.gov>
Betreff: RE: motor model 3 with binary commands PiCo 33 piezo CN30 controller

 

SICHERHEITSHINWEIS: Diese E-Mail wurde von außerhalb an die BAM gesendet. Bitte klicken Sie nicht auf Links oder öffnen Anhänge, bevor Sie nicht den Absender verifiziert haben und sicher sind, dass der Inhalt vertrauenswürdig ist.
This message was sent from outside of BAM. Please do not click links or open attachments unless you recognize the sender and know the content is trustworthy.

Hi Michael,

 

• Do I have to tell him beforehand how many bytes exactly to read?

 

Yes, as Torsten said in this case you need to tell it how many bytes to read, because it is a binary protocol and there is no terminator. 

 

• I tried to set “maxChars=1” (I expect 1 byte). That speed it up but still there seems to be a 0.3s timeout.

 

Are you sure it is a “timeout”, or is it just a delay?  When you using maxChars=1 do you actually see the read operation fail (return non-zero) or do you just see that timestamp has a 0.3 second delay? If it is just a delay then that is normal, it just means that your device takes 0.3 seconds to reply.  That may mean it does not reply until the move is complete.  You can see how the delay varies as you change the move size.

 

In general an asynOctet read request will terminate whenever the following occurs:

• The requested number of characters has been received.
• The timeout occurs before the requested number of characters is received
• The specified terminator has been received.  This is only true if noProcessEos is 0 and an input terminator is specified.
• The underlying device returns an end-of-message.  This applies to GPIB and some other protocols.

 

If the read did not time out then the eomReason argument tells you why the read returned according to the following.

 

#define ASYN_EOM_CNT 0x0001 /*Request count reached*/

#define ASYN_EOM_EOS 0x0002 /*End of String detected*/

#define ASYN_EOM_END 0x0004 /*End indicator detected*/

 

Mark

 

From: Sintschuk, Michael <michael.sintschuk at bam.de>
Sent: Friday, February 2, 2024 10:26 AM
To: Mark Rivers <rivers at cars.uchicago.edu>; tech-talk <tech-talk at aps.anl.gov>
Subject: AW: motor model 3 with binary commands PiCo 33 piezo CN30 controller

 

Hi Mark,

 

thanks for the detailed explanation! Now the right axis is moving, and I understood how the byte-command is actually constructed and send. Also, the outString needs an underline, like this:

pC_->outString_[1]=0;

 

A further question for me is now: is it better to use

              pC_->writeController();

or

              pC_->writeReadController();

?

 

My understanding is, that when I don’t expect an answer from the controller after sending a command I use “writeController();”. But then I don’t know whether the controller understood it or not. And I also don’t know when the controller is ready for the next command.

 

Since the documentation for the PiCo 33 is rather poor, I don’t know if the controller answers after every command send from my driver. I tried using “writeReadController()” and got this as an answer (asynTraces on):

 

every execution of writeReadController() times out after 2 seconds (I guess this is the DEFAULT_CONTROLLER_TIMEOUT=2.0):

 

epics>

epics> 2024/02/02 16:48:32.585 CN30Port asynManager::queueLockPort locking port

2024/02/02 16:48:32.585 CN30Port asynManager::queueLockPort created queueLockPortPvt=0x7fe15c000e20

2024/02/02 16:48:32.585 CN30Port asynManager::queueLockPort created queueLockPortPvt=0x7fe15c000e20, event=0x7fe15c000e40, mutex=0x7fe15c000ee0

2024/02/02 16:48:32.585 CN30Port asynManager::queueLockPort taking mutex 0x7fe15c000ee0

2024/02/02 16:48:32.585 CN30Port asynManager::queueLockPort queueing request

2024/02/02 16:48:32.585 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/02/02 16:48:32.585 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/02/02 16:48:32.585 CN30Port asynManager::queueLockPort waiting for event

2024/02/02 16:48:32.585 asynManager::portThread port=CN30Port callback

2024/02/02 16:48:32.585 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/02/02 16:48:32.585 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/02/02 16:48:32.585 CN30Port asynManager::queueLockPort got event from callback

2024/02/02 16:48:32.585 CN30Port flush

2024/02/02 16:48:32.585 192.168.99.20:4001 flush

2024/02/02 16:48:32.585 192.168.99.20:4001 write.

2024/02/02 16:48:32.585 192.168.99.20:4001 write 1

\x1f

2024/02/02 16:48:32.585 wrote 1 to 192.168.99.20:4001, return asynSuccess.

2024/02/02 16:48:32.585 asynOctetSyncIO wrote:

\x1f

2024/02/02 16:48:32.585 192.168.99.20:4001 read.

2024/02/02 16:48:32.974 192.168.99.20:4001 read 1

2

2024/02/02 16:48:32.974 CN30Port read 1 bytes eom=0

2

2024/02/02 16:48:32.974 192.168.99.20:4001 read.

2024/02/02 16:48:34.976 CN30Port read from low-level driver returned 1

2024/02/02 16:48:34.976 CN30Port queueUnlockPort

2024/02/02 16:48:34.976 CN30Port asynManager::queueUnlockPort waiting for event

2024/02/02 16:48:34.976 CN30Port queueUnlockPort unlock mutex 0x7fe15c000ee0 complete.

2024/02/02 16:48:34.976 CN30Port asynManager::queueLockPort locking port

2024/02/02 16:48:34.976 CN30Port asynManager::queueLockPort taking mutex 0x7fe15c000ee0

2024/02/02 16:48:34.976 CN30Port asynManager::queueLockPort queueing request

2024/02/02 16:48:34.976 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/02/02 16:48:34.976 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/02/02 16:48:34.976 CN30Port asynManager::queueLockPort waiting for event

2024/02/02 16:48:34.976 asynManager::portThread port=CN30Port callback

2024/02/02 16:48:34.976 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/02/02 16:48:34.976 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/02/02 16:48:34.976 CN30Port asynManager::queueLockPort got event from callback

2024/02/02 16:48:34.976 CN30Port flush

2024/02/02 16:48:34.976 192.168.99.20:4001 flush

2024/02/02 16:48:34.976 192.168.99.20:4001 write.

2024/02/02 16:48:34.977 192.168.99.20:4001 write 1

\x1f

2024/02/02 16:48:34.977 wrote 1 to 192.168.99.20:4001, return asynSuccess.

2024/02/02 16:48:34.977 asynOctetSyncIO wrote:

\x1f

2024/02/02 16:48:34.977 192.168.99.20:4001 read.

2024/02/02 16:48:35.366 192.168.99.20:4001 read 1

2

2024/02/02 16:48:35.366 CN30Port read 1 bytes eom=0

2

2024/02/02 16:48:35.366 192.168.99.20:4001 read.

2024/02/02 16:48:37.368 CN30Port read from low-level driver returned 1

2024/02/02 16:48:37.368 CN30Port queueUnlockPort

2024/02/02 16:48:37.368 CN30Port asynManager::queueUnlockPort waiting for event

2024/02/02 16:48:37.368 CN30Port queueUnlockPort unlock mutex 0x7fe15c000ee0 complete.

2024/02/02 16:48:37.368 CN30Port asynManager::queueLockPort locking port

2024/02/02 16:48:37.368 CN30Port asynManager::queueLockPort taking mutex 0x7fe15c000ee0

2024/02/02 16:48:37.368 CN30Port asynManager::queueLockPort queueing request

2024/02/02 16:48:37.368 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/02/02 16:48:37.368 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/02/02 16:48:37.368 CN30Port asynManager::queueLockPort waiting for event

2024/02/02 16:48:37.368 asynManager::portThread port=CN30Port callback

2024/02/02 16:48:37.368 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/02/02 16:48:37.368 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/02/02 16:48:37.368 CN30Port asynManager::queueLockPort got event from callback

2024/02/02 16:48:37.368 CN30Port flush

2024/02/02 16:48:37.368 192.168.99.20:4001 flush

2024/02/02 16:48:37.368 192.168.99.20:4001 write.

2024/02/02 16:48:37.368 192.168.99.20:4001 write 1

\x1f

2024/02/02 16:48:37.368 wrote 1 to 192.168.99.20:4001, return asynSuccess.

2024/02/02 16:48:37.368 asynOctetSyncIO wrote:

\x1f

2024/02/02 16:48:37.368 192.168.99.20:4001 read.

2024/02/02 16:48:37.757 192.168.99.20:4001 read 1

2

2024/02/02 16:48:37.757 CN30Port read 1 bytes eom=0

2

2024/02/02 16:48:37.757 192.168.99.20:4001 read.

2024/02/02 16:48:39.759 CN30Port read from low-level driver returned 1

2024/02/02 16:48:39.759 CN30Port queueUnlockPort

2024/02/02 16:48:39.759 CN30Port asynManager::queueUnlockPort waiting for event

2024/02/02 16:48:39.759 CN30Port queueUnlockPort unlock mutex 0x7fe15c000ee0 complete.

2024/02/02 16:48:39.759 CN30Port asynManager::queueLockPort locking port

2024/02/02 16:48:39.759 CN30Port asynManager::queueLockPort taking mutex 0x7fe15c000ee0

2024/02/02 16:48:39.759 CN30Port asynManager::queueLockPort queueing request

2024/02/02 16:48:39.759 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/02/02 16:48:39.759 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/02/02 16:48:39.759 CN30Port asynManager::queueLockPort waiting for event

2024/02/02 16:48:39.759 asynManager::portThread port=CN30Port callback

2024/02/02 16:48:39.759 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/02/02 16:48:39.759 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/02/02 16:48:39.759 CN30Port asynManager::queueLockPort got event from callback

2024/02/02 16:48:39.759 CN30Port flush

2024/02/02 16:48:39.759 192.168.99.20:4001 flush

2024/02/02 16:48:39.759 192.168.99.20:4001 write.

2024/02/02 16:48:39.759 192.168.99.20:4001 write 1

\x1f

2024/02/02 16:48:39.759 wrote 1 to 192.168.99.20:4001, return asynSuccess.

2024/02/02 16:48:39.759 asynOctetSyncIO wrote:

\x1f

2024/02/02 16:48:39.759 192.168.99.20:4001 read.

2024/02/02 16:48:40.148 192.168.99.20:4001 read 1

2

2024/02/02 16:48:40.148 CN30Port read 1 bytes eom=0

2

2024/02/02 16:48:40.148 192.168.99.20:4001 read.

2024/02/02 16:48:42.150 CN30Port read from low-level driver returned 1

.

.

.

 

But I don’t understand why it times out. Because it gets an answer: 2.

Or is it expecting more to come?

Do I have to tell him beforehand how many bytes exactly to read? I tried to set “maxChars=1” (I expect 1 byte). That speed it up but still there seems to be a 0.3s timeout.

 

Michael

 

Von: Mark Rivers <rivers at cars.uchicago.edu>
Gesendet: Mittwoch, 31. Januar 2024 19:31
An: Mark Rivers <rivers at cars.uchicago.edu>; Sintschuk, Michael <michael.sintschuk at bam.de>; tech-talk <tech-talk at aps.anl.gov>
Betreff: RE: motor model 3 with binary commands PiCo 33 piezo CN30 controller

 

SICHERHEITSHINWEIS: Diese E-Mail wurde von außerhalb an die BAM gesendet. Bitte klicken Sie nicht auf Links oder öffnen Anhänge, bevor Sie nicht den Absender verifiziert haben und sicher sind, dass der Inhalt vertrauenswürdig ist.
This message was sent from outside of BAM. Please do not click links or open attachments unless you recognize the sender and know the content is trustworthy.

Typo in my message.  This line:

        pC_->outString[0]=0;

should be this:

        pC_->outString[1]=0;

 

Mark

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Mark Rivers via Tech-talk
Sent: Wednesday, January 31, 2024 12:29 PM
To: Sintschuk, Michael <michael.sintschuk at bam.de>; tech-talk <tech-talk at aps.anl.gov>
Subject: RE: motor model 3 with binary commands PiCo 33 piezo CN30 controller

 

Hi Michael,

 

• I guess my problem is that this controller talks only in command-bytes and I’m trying to use the model 3 driver which is based on ASCII-commands.

 

The Model 3 driver is not limited to ASCII commands.  The asynMotorController.h has this comment about the writeController(), readController(), etc. methods:

 

  /* These are convenience functions for controllers that use asynOctet interfaces to the hardware */

https://github.com/epics-modules/motor/blob/81662468d0ab2ff0896eb6fbfab214165122ceb2/motorApp/MotorSrc/asynMotorController.h#L302

 

Some vendor software provides library functions rather than a communication protocol, and Model 3 drivers can be used with those.  An example is the Newport XPS where the vendor function GroupMoveAbsolute or GroupMoveRelative is called to move motors:

https://github.com/epics-motor/motorNewport/blob/d84cfe2bf5247475cebd8ce609c219e854c72742/newportApp/src/XPSAxis.cpp#L289

 

In your case the controller does use a communications protocol, but it is binary rather than ASCII.  That means you can still use the asynOctet methods, you just don’t want to convert to ASCII or use terminators.

 

Your controller needs you to send it a single binary byte.  Your code, however, is sending an ASCII string consisting of the characters 0 and 1. 

 

Your code should look something like this.  You can still use pC_->writeController.  This assumes that you never want to send a byte that is binary 0, but I think that is the case.

 

char command;

 

    while (steps2Go > 0) {

        if (steps2Go >= 100)      command=0x7, steps = 100;

        else if (steps2Go >=  50) command=0x6, steps = 50;

        else if (steps2Go >=  20) command=0x5, steps = 20;

        else if (steps2Go >=  10) command=x04, steps = 10;

        else if (steps2Go >=   5) command=0x3, steps = 5;

        else if (steps2Go >=   2) command=0x2, steps = 2;

        else if (steps2Go >=   1) command=0x1, steps = 1;

 

        pC_->outString[0]=command;

        pC_->outString[0]=0;

        pC_->writeController();

 

        epicsThreadSleep(0.001);

 

        steps2Go = steps2Go - steps;

    }

 

You must be sure not to enable terminators on the asyn communications port.

 

Mark

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Sintschuk, Michael via Tech-talk
Sent: Wednesday, January 31, 2024 10:30 AM
To: tech-talk <tech-talk at aps.anl.gov>
Subject: motor model 3 with binary commands PiCo 33 piezo CN30 controller

 

Dear all,

 

I’m struggling to write a motor driver for an old piezo controller that goes by the name CN30 or PiCo 33 from Mechonics.

I guess my problem is that this controller talks only in command-bytes and I’m trying to use the model 3 driver which is based on ASCII-commands. I attached a pdf with a description of the RS232 command-byte and I also found a SPEC driver for this controller: BLISS: SPEC Macro documentation / Macrofile: mechonics.mac (esrf.fr)

 

This is my move function from the driver:

 

asynStatus CN30Axis::move(double position, int relative, double baseVelocity, double slewVelocity, double acceleration)

{

    asynStatus status;

    size_t nwrite;

    int steps, steps2Go;

    char nsteps[4];

    // static const char *functionName = "CN30Axis::move";

 

    // calculate how many steps to do, ca. 200nm/Step and we drive in mm

    steps2Go = static_cast<int>(position / 200e-7);

    while (steps2Go > 0) {

        if (steps2Go >= 100) strcpy(nsteps, "111"), steps = 100;

        else if (steps2Go >=  50) strcpy(nsteps, "110"), steps = 50;

        else if (steps2Go >=  20) strcpy(nsteps, "101"), steps = 20;

        else if (steps2Go >=  10) strcpy(nsteps, "100"), steps = 10;

        else if (steps2Go >=   5) strcpy(nsteps, "011"), steps = 5;

        else if (steps2Go >=   2) strcpy(nsteps, "010"), steps = 2;

        else if (steps2Go >=   1) strcpy(nsteps, "001"), steps = 1;

 

        sprintf(pC_->outString_, "00000%s", nsteps);

        pC_->writeController();

 

        epicsThreadSleep(0.001);

 

        steps2Go = steps2Go - steps;

    }

    return status;

}

 

Here is the IOC console output with asynTraces turned on when trying to do a 1mm move (I also need to work on the step-resolution but this is not the issue right now):

 

00000111

2024/01/31 16:44:55.492 CN30Port queueUnlockPort

2024/01/31 16:44:55.492 CN30Port asynManager::queueUnlockPort waiting for event

2024/01/31 16:44:55.492 CN30Port queueUnlockPort unlock mutex 0x7f5098000ee0 complete.

2024/01/31 16:44:55.493 CN30Port asynManager::queueLockPort locking port

2024/01/31 16:44:55.493 CN30Port asynManager::queueLockPort taking mutex 0x7f5098000ee0

2024/01/31 16:44:55.493 CN30Port asynManager::queueLockPort queueing request

2024/01/31 16:44:55.493 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/01/31 16:44:55.493 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/01/31 16:44:55.493 CN30Port asynManager::queueLockPort waiting for event

2024/01/31 16:44:55.493 asynManager::portThread port=CN30Port callback

2024/01/31 16:44:55.493 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/01/31 16:44:55.493 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/01/31 16:44:55.493 CN30Port asynManager::queueLockPort got event from callback

2024/01/31 16:44:55.493 192.168.99.20:4001 write.

2024/01/31 16:44:55.493 192.168.99.20:4001 write 8

00000111

2024/01/31 16:44:55.493 wrote 8 to 192.168.99.20:4001, return asynSuccess.

2024/01/31 16:44:55.493 asynOctetSyncIO wrote:

00000111

2024/01/31 16:44:55.493 CN30Port queueUnlockPort

2024/01/31 16:44:55.493 CN30Port asynManager::queueUnlockPort waiting for event

2024/01/31 16:44:55.493 CN30Port queueUnlockPort unlock mutex 0x7f5098000ee0 complete.

2024/01/31 16:44:55.495 CN30Port asynManager::queueLockPort locking port

2024/01/31 16:44:55.495 CN30Port asynManager::queueLockPort taking mutex 0x7f5098000ee0

2024/01/31 16:44:55.495 CN30Port asynManager::queueLockPort queueing request

2024/01/31 16:44:55.495 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/01/31 16:44:55.495 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/01/31 16:44:55.495 CN30Port asynManager::queueLockPort waiting for event

2024/01/31 16:44:55.495 asynManager::portThread port=CN30Port callback

2024/01/31 16:44:55.495 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/01/31 16:44:55.495 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/01/31 16:44:55.495 CN30Port asynManager::queueLockPort got event from callback

2024/01/31 16:44:55.495 192.168.99.20:4001 write.

2024/01/31 16:44:55.495 192.168.99.20:4001 write 8

00000111

2024/01/31 16:44:55.495 wrote 8 to 192.168.99.20:4001, return asynSuccess.

2024/01/31 16:44:55.495 asynOctetSyncIO wrote:

00000111

2024/01/31 16:44:55.495 CN30Port queueUnlockPort

2024/01/31 16:44:55.495 CN30Port asynManager::queueUnlockPort waiting for event

2024/01/31 16:44:55.495 CN30Port queueUnlockPort unlock mutex 0x7f5098000ee0 complete.

2024/01/31 16:44:55.496 CN30Port asynManager::queueLockPort locking port

2024/01/31 16:44:55.496 CN30Port asynManager::queueLockPort taking mutex 0x7f5098000ee0

2024/01/31 16:44:55.496 CN30Port asynManager::queueLockPort queueing request

2024/01/31 16:44:55.496 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/01/31 16:44:55.496 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/01/31 16:44:55.496 CN30Port asynManager::queueLockPort waiting for event

2024/01/31 16:44:55.496 asynManager::portThread port=CN30Port callback

2024/01/31 16:44:55.496 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/01/31 16:44:55.496 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/01/31 16:44:55.496 CN30Port asynManager::queueLockPort got event from callback

2024/01/31 16:44:55.496 192.168.99.20:4001 write.

2024/01/31 16:44:55.496 192.168.99.20:4001 write 8

00000110

2024/01/31 16:44:55.496 wrote 8 to 192.168.99.20:4001, return asynSuccess.

2024/01/31 16:44:55.496 asynOctetSyncIO wrote:

00000110

2024/01/31 16:44:55.496 CN30Port queueUnlockPort

2024/01/31 16:44:55.496 CN30Port asynManager::queueUnlockPort waiting for event

2024/01/31 16:44:55.496 CN30Port queueUnlockPort unlock mutex 0x7f5098000ee0 complete.

2024/01/31 16:44:55.497 CN30Port asynManager::queueLockPort locking port

2024/01/31 16:44:55.497 CN30Port asynManager::queueLockPort taking mutex 0x7f5098000ee0

2024/01/31 16:44:55.497 CN30Port asynManager::queueLockPort queueing request

2024/01/31 16:44:55.497 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/01/31 16:44:55.497 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/01/31 16:44:55.497 CN30Port asynManager::queueLockPort waiting for event

2024/01/31 16:44:55.497 asynManager::portThread port=CN30Port callback

2024/01/31 16:44:55.497 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/01/31 16:44:55.497 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/01/31 16:44:55.497 CN30Port asynManager::queueLockPort got event from callback

2024/01/31 16:44:55.497 192.168.99.20:4001 write.

2024/01/31 16:44:55.497 192.168.99.20:4001 write 8

00000101

2024/01/31 16:44:55.497 wrote 8 to 192.168.99.20:4001, return asynSuccess.

2024/01/31 16:44:55.497 asynOctetSyncIO wrote:

00000101

2024/01/31 16:44:55.497 CN30Port queueUnlockPort

2024/01/31 16:44:55.497 CN30Port asynManager::queueUnlockPort waiting for event

2024/01/31 16:44:55.497 CN30Port queueUnlockPort unlock mutex 0x7f5098000ee0 complete.

2024/01/31 16:44:55.498 CN30Port asynManager::queueLockPort locking port

2024/01/31 16:44:55.498 CN30Port asynManager::queueLockPort taking mutex 0x7f5098000ee0

2024/01/31 16:44:55.498 CN30Port asynManager::queueLockPort queueing request

2024/01/31 16:44:55.498 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/01/31 16:44:55.498 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/01/31 16:44:55.498 CN30Port asynManager::queueLockPort waiting for event

2024/01/31 16:44:55.498 asynManager::portThread port=CN30Port callback

2024/01/31 16:44:55.498 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/01/31 16:44:55.498 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/01/31 16:44:55.498 CN30Port asynManager::queueLockPort got event from callback

2024/01/31 16:44:55.498 192.168.99.20:4001 write.

2024/01/31 16:44:55.498 192.168.99.20:4001 write 8

00000101

2024/01/31 16:44:55.498 wrote 8 to 192.168.99.20:4001, return asynSuccess.

2024/01/31 16:44:55.498 asynOctetSyncIO wrote:

00000101

2024/01/31 16:44:55.499 CN30Port queueUnlockPort

2024/01/31 16:44:55.499 CN30Port asynManager::queueUnlockPort waiting for event

2024/01/31 16:44:55.499 CN30Port queueUnlockPort unlock mutex 0x7f5098000ee0 complete.

2024/01/31 16:44:55.500 CN30Port asynManager::queueLockPort locking port

2024/01/31 16:44:55.500 CN30Port asynManager::queueLockPort taking mutex 0x7f5098000ee0

2024/01/31 16:44:55.500 CN30Port asynManager::queueLockPort queueing request

2024/01/31 16:44:55.500 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/01/31 16:44:55.500 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/01/31 16:44:55.500 CN30Port asynManager::queueLockPort waiting for event

2024/01/31 16:44:55.500 asynManager::portThread port=CN30Port callback

2024/01/31 16:44:55.500 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/01/31 16:44:55.500 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/01/31 16:44:55.500 CN30Port asynManager::queueLockPort got event from callback

2024/01/31 16:44:55.500 192.168.99.20:4001 write.

2024/01/31 16:44:55.500 192.168.99.20:4001 write 8

00000011

2024/01/31 16:44:55.500 wrote 8 to 192.168.99.20:4001, return asynSuccess.

2024/01/31 16:44:55.500 asynOctetSyncIO wrote:

00000011

2024/01/31 16:44:55.500 CN30Port queueUnlockPort

2024/01/31 16:44:55.500 CN30Port asynManager::queueUnlockPort waiting for event

2024/01/31 16:44:55.500 CN30Port queueUnlockPort unlock mutex 0x7f5098000ee0 complete.

2024/01/31 16:44:55.501 CN30Port asynManager::queueLockPort locking port

2024/01/31 16:44:55.501 CN30Port asynManager::queueLockPort taking mutex 0x7f5098000ee0

2024/01/31 16:44:55.501 CN30Port asynManager::queueLockPort queueing request

2024/01/31 16:44:55.501 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/01/31 16:44:55.501 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/01/31 16:44:55.501 CN30Port asynManager::queueLockPort waiting for event

2024/01/31 16:44:55.501 asynManager::portThread port=CN30Port callback

2024/01/31 16:44:55.501 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/01/31 16:44:55.501 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/01/31 16:44:55.501 CN30Port asynManager::queueLockPort got event from callback

2024/01/31 16:44:55.501 192.168.99.20:4001 write.

2024/01/31 16:44:55.501 192.168.99.20:4001 write 8

00000010

2024/01/31 16:44:55.501 wrote 8 to 192.168.99.20:4001, return asynSuccess.

2024/01/31 16:44:55.501 asynOctetSyncIO wrote:

00000010

2024/01/31 16:44:55.501 CN30Port queueUnlockPort

2024/01/31 16:44:55.501 CN30Port asynManager::queueUnlockPort waiting for event

2024/01/31 16:44:55.501 CN30Port queueUnlockPort unlock mutex 0x7f5098000ee0 complete.

2024/01/31 16:44:55.502 CN30Port asynManager::queueLockPort locking port

2024/01/31 16:44:55.502 CN30Port asynManager::queueLockPort taking mutex 0x7f5098000ee0

2024/01/31 16:44:55.502 CN30Port asynManager::queueLockPort queueing request

2024/01/31 16:44:55.502 CN30Port addr -1 queueRequest priority 0 not lockHolder

2024/01/31 16:44:55.502 CN30Port schedule queueRequest timeout in 2.000000 seconds

2024/01/31 16:44:55.502 CN30Port asynManager::queueLockPort waiting for event

2024/01/31 16:44:55.502 asynManager::portThread port=CN30Port callback

2024/01/31 16:44:55.502 CN30Port asynManager::queueLockPortCallback signaling begin event

2024/01/31 16:44:55.502 CN30Port asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort

2024/01/31 16:44:55.502 CN30Port asynManager::queueLockPort got event from callback

2024/01/31 16:44:55.502 192.168.99.20:4001 write.

2024/01/31 16:44:55.502 192.168.99.20:4001 write 8

00000010

2024/01/31 16:44:55.502 wrote 8 to 192.168.99.20:4001, return asynSuccess.

2024/01/31 16:44:55.502 asynOctetSyncIO wrote:

00000010

2024/01/31 16:44:55.502 CN30Port queueUnlockPort

2024/01/31 16:44:55.502 CN30Port asynManager::queueUnlockPort waiting for event

2024/01/31 16:44:55.502 CN30Port queueUnlockPort unlock mutex 0x7f5098000ee0 complete.

 

epics>

 

I can see the axis moving, but it is the wrong axis because Bit 7 and 6 are actually 0 (see attached pdf).

 

Also, the command 00000111 in the output looks right I’m not sure if the controller understands it. Is it right to use:

        sprintf(pC_->outString_, "00000%s", nsteps);

        pC_->writeController();

when I want to send a byte-command? Does it matter?

So far, I only have experience in write ASCII-based motor drivers, based on examples of model 3.

Can someone help?

 

Thanks, and best regards!

Michael

 

 

Michael Sintschuk
Bundesanstalt für Materialforschung und –prüfung (BAM)
8.5 - X-ray Imaging

Unter den Eichen 87
12205 Berlin
GERMANY

P: +49 30 8062-15063 (BESSY, Adlershof)
michael.sintschuk at bam.de