Experimental Physics and
Industrial Control System

Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov> · Fri, 2 Feb 2024 18:17:32 +0100

Hej Michael,
some thoughts inline.

On 2024-02-02 17:26, Sintschuk, Michael via Tech-talk wrote:

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

Hej Michael,
yes ;-)

There are 2 ways to write/read a controller:
ASCII or BINARY
When using ASCII (which most controllers do), we can search for
the "line terminator" when receiving, and find out,
that the message is complete.
That assumes, that the answer is all on "one line".
Either terminated with an LF, a CRLF or a CR.
Many controllers work this way:
One request/send from the IOC, one response from the controller.

When dealing with BINARY data, things are more complicated.
Since TCP is a byte stream protocol, answers may, in theory, split
up into different segments over the wire.
Even in practise, some RS232 - Ethernet converters do this,
depending on the timing.
As a consequence, the asyn layer needs either to know, how
many bytes (strictly speakinf octets) to receive.
Here you have 2 choices:
Specify the exact length and get the answer directly or
Specify a longer buffer, just in case, and be "punished" by the
timeout.

This is a dilemma.
If your controller sends only 1 byte back, then try to receive 1 byte.
For another binary communication I had to split this operation into
2 calls:
pasynOctetSyncIO->write()
and
pasynOctetSyncIO->read()

See here, in our case 2 reads may be needed, since the first returns
a header, in which we can read if, and how many, bytes to receive
after the header:

<https://github.com/EuropeanSpallationSource/m-epics-ethercatmc/blob/master/ethercatmcApp/src/ethercatmcADS.cpp#L228-LL265>

HTH
/Torsten

*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

<mailto: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

<mailto:michael.sintschuk at bam.de>>; tech-talk <tech-talk at aps.anl.gov

<mailto: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 <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 <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

<mailto: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 <mailto: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)

<https://www.esrf.fr/blissdb/macros/getsource.py?macname=mechonics.mac>

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 <mailto:michael.sintschuk at bam.de>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System