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
<https://github.com/MichaS-git/motorMicos/blob/master/micosApp/src/CN30Driver.cpp>
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
<mailto:rivers at cars.uchicago.edu>>
*Gesendet:* Freitag, 2. Februar 2024 18:37
*An:* 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>>
*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
<mailto:michael.sintschuk at bam.de>>
*Sent:* Friday, February 2, 2024 10:26 AM
*To:* Mark Rivers <rivers at cars.uchicago.edu
<mailto:rivers at cars.uchicago.edu>>; tech-talk <tech-talk at aps.anl.gov
<mailto: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
<mailto:rivers at cars.uchicago.edu>>
*Gesendet:* Mittwoch, 31. Januar 2024 19:31
*An:* Mark Rivers <rivers at cars.uchicago.edu
<mailto:rivers at cars.uchicago.edu>>; 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>>
*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>
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·