dls-controls / pmac

Driver for the Delta Tau PMAC motion controller family.

pmac

EPICS driver and support module for the Delta Tau PMAC motion controller family.

pmac's Issues

String PV

Hello,

I am writing a custom Background Program in C language to perform fast gathers.

One specification is that the user could be able to set the output file name on the GUI. By this reason, I would like to know if there is something related to read and write strings on PowerPMAC.

I saw this snippet of code on pmacVariableWrite template:

record(ao, "$(P)$(Q):SET") {
  field(DESC, "Write value to pmac")
  field(DTYP, "$(DTYP=asynFloat64)")
  field(SDIS, "$(P)$(Q):SYNC.PACT")
  field(OUT, "@asyn($(PORT),0)PMAC_W$(TYPE=D)_$(VAR)")
}

and maybe this TYPE is the solution for my problem. I don`t know how to use it on both sides: EPICS and PowerPMAC; and I would like some help on it.

I also would like to know if I could just adapt TYPE of the same template on tag 2-4-11 which is the running version on our entire lab. The following snippet of the same template for the variable write template of version 2-4-11 (Note that TYPE does not exist)

record(ao, "$(P)$(Q):SET") {
  field(DESC, "Write value to pmac")
  field(DTYP, "asynFloat64")
  field(SDIS, "$(P)$(Q):SYNC.PACT")
  field(OUT, "@asyn($(PORT),0)PMAC_VDM_$(VAR)")

The Cdata shared memory was designed for string manipulation, could I have access to it from pmacVariableWrite?

Thanks in advance
George

Feed rate error on kinematic

Hello, how are you?

I'm using PMAC IOC and need some help. I'm getting erro of feed rate belowe the limit when I enable kinematic on .cmd file. Is there any problem with my configuration? how can I fix this error?

---

".cmd file"

epicsEnvSet("PPMAC_CS2_PORT", "CS2")

#****************************************************************************************

ATTACH TO THE SSH PORT

drvAsynPowerPMACPortConfigure("$(PPMAC_SSH_PORT)", "$(PPMAC_IP)", "xxxxx", "xxxxxx", "0", "0", "0")

#****************************************************************************************

CONFIGURE MODEL 3 CONTROLLER DRIVER

pmacCreateController("$(PPMAC_PORT)", "$(PPMAC_SSH_PORT)", 0 , 8, 100, 1000)

#****************************************************************************************

CREATE THE MODEL 3 MOTION AXIS DRIVERS

pmacCreateAxes("$(PPMAC_PORT)", 8)

#****************************************************************************************

SET UP FOR RUNNING COORDINATE SYSTEMS

pmacCreateCS("$(PPMAC_CS1_PORT)", "$(PPMAC_PORT)", 1, 1)

##****************************************************************************************

CREATE COORDINATE SYSTEMS AXES

pmacCreateCSAxes("$(PPMAC_CS1_PORT)", 9)

##****************************************************************************************

SET COORDINATE SYSTEM 1 SCALE FACTOR

pmacSetCoordStepsPerUnit("$(PPMAC_CS1_PORT)", 7, 1)
pmacSetCoordStepsPerUnit("$(PPMAC_CS1_PORT)", 8, 1)

"Kinematic"

open forward (1)
if (KinVelEna) callsub 100;
KinAxisUsed = KinEnaAxisX | KinEnaAxisY
N100: if(1) {
//A = angle relative to center; B = center offset
KinPosAxisX = 0.5 * (KinPosMotor5 + KinPosMotor6)
KinPosAxisY = 0.5 * (KinPosMotor5 - KinPosMotor6)
}
else
{
//Error message for different call paths:
if (Ldata.Status &40) {
Coord[1].ErrorStatus = 255; // User-set aborting error
}
else {
KinPosAxisX = sqrt(-1); // Return 'NaN'
KinPosAxisY = sqrt(-1); // Return 'NaN'
}
}
return;
close

---

Problems with PowerPMAC

Hi, We are having some problems with our PowerPMAC when we use an specific code inside controller (if we use factory setup this problem doesn't happen). The problem looks related with m-variables. The IOC prints messages like:

pmacController::mediumUpdate Problem reading PLC program status => M5022

Is necessary to use an specific code in DeltaTau to use the IOC? Or I can suppose any code will work?

pmacAsynIPPortSrc does not build on windows-x64

The following change is required to build pmacAsynIPPortSrc on windows-x64, i.e. to build the dll.

diff --git a/pmacApp/pmacAsynIPPortSrc/Makefile b/pmacApp/pmacAsynIPPortSrc/Makefile
index 9312f83..55e5874 100644
--- a/pmacApp/pmacAsynIPPortSrc/Makefile
+++ b/pmacApp/pmacAsynIPPortSrc/Makefile
@@ -10,4 +10,8 @@ INC += pmacAsynIPPort.h
 LIBRARY = pmacAsynIPPort
 pmacAsynIPPort_SRCS = pmacAsynIPPort.c

+pmacAsynIPPort_LIBS += asyn
+pmacAsynIPPort_LIBS += $(EPICS_BASE_IOC_LIBS)
+pmacAsynIPPort_SYS_LIBS_WIN32 += ws2_32
+
 include $(TOP)/configure/RULES

PPMAC - Invalid lookahead definition when switching CS Groups

The redefineLookaheads method currently uses commands that are exclusive to TurboPMAC, making it ineffective for PowerPMAC. This difference can lead to incorrect or non-existent allocation for coordinate systems when switching between defined CsGroups.

Key differences between TurboPMAC and PowerPMAC that are relevant to this issue include:

• PowerPMAC does not require a specific order to define lookahead buffers for each coordinate system, unlike TurboPMAC which requires definition from high-numbered to low-numbered coordinate systems.

• PowerPMAC has a minimum lookahead buffer size of 1024.

• PowerPMAC only accepts the define lookahead command for coordinate systems that have a number of assigned motors greater than zero. Although it is possible to directly set Coord[x].LHSize (which reflects the buffer size defined by the define lookahead command) without any restriction on the number of motors assigned, it is unclear if the allocation occurs correctly. As per the Power PMAC Software Reference Manual (May 19, 2023, p.853), it is stated that “it is not possible to write to it directly in the Script environment.”

This issue is to keep track of the changes necessary to ensure compatibility of the redefineLookaheads method with both TurboPMAC and PowerPMAC, and to guarantee correct lookahead definition when switching between CS Groups, regardless of the PPMAC type in use.

EPICS "gantry follower" mode

Hi,

I configured a system as a "gantry follower" to perform identical movements on two different engines, being M1-Leader and M2-Follower.

However, for the synchronized movements to take place, both engines must have the "enable" state active.

Moving the system through the PowerPmac IDE terminal, I need to sequence the commands:

• #1..2j/
• #1j^1000 (for example)

I configured the IOC with the M1 and when executing a motion command (with the 2 motors out of the "enable" state), only the M1 moved.

Is there a way to put the engines in j/ before all movement via EPICS?

libssh2 has been deprecated in RHEL 7, removed in RHEL 8.

This module is built on libssh2, and that library has been deprecated by Redhat.

Crash with "floating point exception"

Hi Giles,
I try to run the iocs/example. when run the command "pmacCreateController("Brick", "BRICK1port", 0, 8, 100, 200)" , it gives a error "floating point exception" and EPICS exist.
I use the Ubuntu 18.04LTS, Geobrick LV . Do I use the right example for Geobrick?
Thank you!

Best,
Yajun

PMAC PCI

Hi,
This is a question more than an ‘issue’, so apologies if this isn’t the place to ask it. We have a PMAC PCI (the plain old PCI version—not the turbo) and we would like to retire the old XP control computer that communicates with it using the PCI bus. Does this software also support our PMAC PCI?

Thanks!
Dallan
MMT Observatory
Tucson, AZ

Compile error on vxWorks

When I try to build the master branch (or 2-4-10) on vxWorks 6.9.4.1 I get the following error:

make[3]: Entering directory `/home/epics/devel/pmac-2-5-13/pmacApp/pmacAsynVMEPortSrc/O.vxWorks-ppc32'
/usr/local/vw/vxWorks-6.9.4/gnu/4.3.3-vxworks-6.9/x86-linux2/bin/ccppc            -DCPU=PPC32  -DvxWorks=vxWorks -include /usr/local/vw/vxWorks-6.9.4/vxworks-6.9/target/h/vxWorks.h     -O2   -Wall -Werror-implicit-function-declaration     -DSTATUS_RECORD  -mstrict-align -mlongcall    -fno-builtin  -I. -I../O.Common -I. -I. -I.. -I../../../include/compiler/gcc -I../../../include/os/vxWorks -I../../../include       -I/corvette/usr/local/epics-devel/base-7.0.5/include/compiler/gcc -I/corvette/usr/local/epics-devel/base-7.0.5/include/os/vxWorks -I/corvette/usr/local/epics-devel/base-7.0.5/include   -I/corvette/home/epics/devel/asyn-4-42/include   -I/corvette/home/epics/devel/calc-3-7-3/include   -I/corvette/home/epics/devel/motor-7-0/include   -I/corvette/home/epics/devel/busy-1-7-2/include       -I/usr/local/vw/vxWorks-6.9.4/vxworks-6.9/target/h -I/usr/local/vw/vxWorks-6.9.4/vxworks-6.9/target/h/wrn/coreip -c ../devPmacRam.c
In file included from /corvette/usr/local/epics-devel/base-7.0.5/include/dbAccess.h:20,
                 from ../devPmacRam.c:89:
/corvette/usr/local/epics-devel/base-7.0.5/include/dbBase.h:164: warning: 'rset' is deprecated
In file included from /corvette/usr/local/epics-devel/base-7.0.5/include/dbAccess.h:24,
                 from ../devPmacRam.c:89:
/corvette/usr/local/epics-devel/base-7.0.5/include/dbAccessDefs.h:211: warning: 'rset' is deprecated
../devPmacRam.c: In function 'devPmacRamEvent_read':
../devPmacRam.c:1075: error: incompatible types in assignment
make[3]: *** [devPmacRam.o] Error 1
make[3]: Leaving directory `/home/epics/devel/pmac-2-5-13/pmacApp/pmacAsynVMEPortSrc/O.vxWorks-ppc32'

StopAll and KillAll forces reconnection for Power PMAC

The commands used for StopAll (\x01) and KillAll (\x0b) are not valid for Power PMAC.

As the controller doesn't reply as expected, the driver understand that as a connection lost, forcing a reconnection.
If a sequence of these commands were sent, the connection would be restarted a few times before being initialized properly.

Issue with BOOST_MESSAGE in pmacApp/unitTest

Hi,

I have just created a fresh installation of pmac module on my system (Ubuntu 18.04), but I found some issues with the unit tests.

Versions used:

- pmac: master (ae2603b98d98e49d1c1392c1d3839139bc063cf0)
- boost: 1.65.1

I had to modify files in pmacApps/unitTests as shown in the attached patch.

boost_test_message.txt

Best regards,

Žiga

Invert state of :PLCDISBITS00 and :PLCDISBITS01 for PowerPMAC to match TurboPMAC Readback

m-variables m5000..m032 report the running state of PLCs on both Turbo and Power PMACs. However on TurboPMAC a value of 1 indicates PLC disabled, whereas on Power PMAC a value of 1 indicates PLC enabled.

This means that the pmacController screen displays the wrong state for PowerPMAC PLCs, and also affects the input to separate tools such as DeltaTauPLCStat. This module gets the state of PLCs from the pmac driver's PVs (as opposed to requesting the state from the controller directly)

The driver should change the sense of the PVs served depending on whether it is talking to a Turbo/PowerPMAC controller

Intermittent connection dropout, even when all motor channels are completely idle

We have been running into an issue with several of our PowerBrick controllers at NSLS-II that we haven't been able to diagnose/resolve. Essentially, every 3-5 days or so, we get the below in the IOC shell:

epics> 2023/08/30 18:28:29.475 pmacHardwareTurbo::parseAxisStatus Failed to parse axis status (24 bit) =>  0
2023/08/30 18:28:29.475 pmacHardwareTurbo::parseAxisStatus Failed to parse axis status (16 bit) =>  0
2023/08/30 18:28:29.475 getAxisStatus: Failed to parse position. Key: #6P  Value:  $0000c10000000000
2023/08/30 18:28:29.475 getAxisStatus: Failed to parse following error. Key: #7F  Value: d
2023/08/31 07:38:39.304 pmacMessageBroker::lowLevelWriteRead Connection to hardware lost
2023/08/31 07:38:41.689296 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C2R}AxisEnable-Sts: Input "<0a>M139=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.690074 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C1Y}AxisEnable-Sts: Input "<0a>M239=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.690800 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C1P}AxisEnable-Sts: Input "<0a>M339=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.691481 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C2P}AxisEnable-Sts: Input "<0a>M439=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.692103 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:BS}AxisEnable-Sts: Input "<0a>M539=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.692866 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:FS}AxisEnable-Sts: Input "<0a>M639=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.693568 P0 XF:27IDA-OP:1{MC:3-Ax:7}AxisEnable-Sts: Input "<0a>M739=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.694409 P0 XF:27IDA-OP:1{MC:3-Ax:8}AxisEnable-Sts: Input "<0a>M839=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.695198 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C2R}PhaseCur-I: Input "<0a>M176=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.696033 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C1Y}PhaseCur-I: Input "<0a>M276=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.696679 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C1P}PhaseCur-I: Input "<0a>M376=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.697360 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C2P}PhaseCur-I: Input "<0a>M476=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.698163 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:BS}PhaseCur-I: Input "<0a>M576=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.698870 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:FS}PhaseCur-I: Input "<0a>M676=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.699585 P0 XF:27IDA-OP:1{MC:3-Ax:7}PhaseCur-I: Input "<0a>M776=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.700237 P0 XF:27IDA-OP:1{MC:3-Ax:8}PhaseCur-I: Input "<0a>M876=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.700939 P0 XF:27IDA-CT{MC:03-Ax:1}Cur-I: Input "<0a>M176=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.701610 P0 XF:27IDA-CT{MC:03-Ax:2}Cur-I: Input "<0a>M276=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.702364 P0 XF:27IDA-CT{MC:03-Ax:3}Cur-I: Input "<0a>M376=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.702967 P0 XF:27IDA-CT{MC:03-Ax:4}Cur-I: Input "<0a>M476=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.703614 P0 XF:27IDA-CT{MC:03-Ax:5}Cur-I: Input "<0a>M576=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.704267 P0 XF:27IDA-CT{MC:03-Ax:6}Cur-I: Input "<0a>M676=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.704949 P0 XF:27IDA-CT{MC:03-Ax:7}Cur-I: Input "<0a>M776=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.705593 P0 XF:27IDA-CT{MC:03-Ax:8}Cur-I: Input "<0a>M876=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.709579 P0 XF:27IDA-CT{MC:03}Val:CPULoad-I: Input "<0a>P575=0<0d><0a>" does not match format "%f"
2023/08/31 07:38:41.710145 P0 XF:27IDA-CT{MC:03}Enbl:PLC_W0-Sts: Input "<0a>P592=1280<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.710715 P0 XF:27IDA-CT{MC:03}Val:Pgm-Sts: Input "<0a>P596=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.711276 P0 XF:27IDA-CT{MC:03}Cnt:MACRO_Err-I: Input "<0a>M5035=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.711846 P0 XF:27IDA-CT{MC:03}Val:CPUTemp-I: Input "<0a>Sys.CpuTemp=0<0d><0a>" does not match format "%f"
2023/08/31 07:38:41.712535 P0 XF:27IDA-CT{MC:03}In:GPIO-Sts: Input "<0a>P594=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.713111 P0 XF:27IDA-CT{MC:03}Out:GPIO-Sel: Input "<0a>P595=0<0d><0a>" does not match format "%d"
2023/08/31 07:38:41.721774 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C2R}Flt:ELoss-Sts: Input "<0a>P465=0<0d><0a>" does not match format "%i"
2023/08/31 07:38:41.722302 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C1Y}Flt:ELoss-Sts: Input "<0a>P466=0<0d><0a>" does not match format "%i"
2023/08/31 07:38:41.722951 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C1P}Flt:ELoss-Sts: Input "<0a>P467=0<0d><0a>" does not match format "%i"
2023/08/31 07:38:41.723458 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:C2P}Flt:ELoss-Sts: Input "<0a>P468=0<0d><0a>" does not match format "%i"
2023/08/31 07:38:41.724001 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:BS}Flt:ELoss-Sts: Input "<0a>P469=0<0d><0a>" does not match format "%i"
2023/08/31 07:38:41.724527 P0 XF:27IDA-OP:1{Mono:DCLM-Ax:FS}Flt:ELoss-Sts: Input "<0a>P470=0<0d><0a>" does not match format "%i"
2023/08/31 07:38:41.725059 P0 XF:27IDA-OP:1{MC:3-Ax:7}Flt:ELoss-Sts: Input "<0a>P471=0<0d><0a>" does not match format "%i"
2023/08/31 07:38:41.725674 P0 XF:27IDA-OP:1{MC:3-Ax:8}Flt:ELoss-Sts: Input "<0a>P472=0<0d><0a>" does not match format "%i"
2023/08/31 07:38:41.731 pmacMessageBroker::getConnectedStatus Connection to hardware restored
2023/08/31 07:38:41.733771 P0 XF:27IDA-CT{MC:03}Enbl:PLC_W1-Sts: Input "<0a>P593=0<0d><0a>" does not match format "%d"

The only solution once this crops up is to reboot the IOC, and sometimes, reboot the controller as well. Has anyone else seen this behavior? Could this be caused by anything on the IOC or the controller network stack? We were able to verify that hardware did not power cycle, and we don't believe the network globally dropped out - other IOCs did not lose connection to instruments during the same time (even other PowerBricks - this occurs at varied times for different controllers).

Global variables as PVs

Hello!

I would like to know if there is a way to read global variables on IOC level, as it does with M-variables on GPIO or Plc[i].Running. If there is any feature to read P-variables I guess that it could be possible.

On my project I will use the PV SendCmd to read custom variables but I would like to know if there is a fashionable form to do it.

Thanks
George

Owner for Debug messages for pmacHardwarePower is wrong

The debug messages for pmacHardwarePower indicates pmacHardwareTurbo as the source of the problem. This is due to the owner of debug instance, which is defined at pmacHardwarePower.cpp , line 43

EPICS way for "Closed Loop"

Hi!

I would like to know if it is possible to do "closed loop" by iterations as EPICS usually do, on its level or I have to write a custom plc script to perform that movement?

Thanks!
George

Global status bits doesn't support PowerPMAC

The global status bits currently in use are specifi for TurboPMAC.
This could lead to misleading errors and a failure to detect actual errors for PowerPMAC.

homing from EPICS

Hi!

We have, sometimes, to enable some plc script to do the correct movements to find the encoder reference mark. We thought about sending a enable plc xxxx by SendCmd PV, but I saw some home PVs. Is there a way to perform homing procedure from PV in a custom way?

Thanks!
George

PPMAC - global Time in trajectory_scan_definitions_ppmac.pmh breaks Sys.Time

global Time in trajectory_scan_definitions_ppmac.pmh breaks Sys.Time.
We need to use a different name for the trajectory time for the PPMAC.

dkill from EPICS

Hi!

Is there a way to perform a dkill from some PV?

I have to do it in order to engage brakes in a correct way

Thanks!

PPMAC - Disable limits not supported

In TurboPMAC, the limits are monitored by examining the ix24 variables. However, in PowerPMAC, ix24 represents the address of the servo-loop being used. PowerPMAC also includes protection against writing to invalid addresses.
The element Motor[%d].pLimits should be used instead.

This difference makes operations like i%d24=i%d24&$FDFFFF and i%d24=i%d24|$20000 invalid in PowerPMAC. Moreover, these operations do not disable or enable the limits as one might expect.
The correct operation should be something like Motor[%d].pLimits=0 for disabing, and Motor[%d].pLimits=Gate3[%d].Chan[%d].Status.a for enabling (preferably that address should be stored when disabling the limits).

When checking ix24, the response formats differ between TurboPMAC and PowerPMAC:

• TurboPMAC uses the $%x format.
• PowerPMAC uses the %d format.

Ultimately, these differences might lead to undesired behavior in two scenarios:

• When homing into the limits, which is necessary to disable the limit faults.
• When performing a safety check present in pmacAxis::getAxisStatus, which flags if the limits are disabled without the driver’s knowledge.

Compile error on CentOS7

When building on CentOS7, the following compiler error occurs:

../devPmacRam.c: In function ‘devPmacRamEvent_read’: ../devPmacRam.c:1064:13: error: incompatible types when assigning to type ‘char[40]’ from type ‘short int’ pRec->val = (short) (0x0000ffff & pDpvt->dpramData.ramLong);
I will submit a pull request for review to (hopefully) address this.

How to use this IOC with PowerPMAC

Hi, How I can use this IOC with PowerPMAC?

I'm trying to use iocbuilder, but there are some dependencies I can't solve (dls_ade)

Trajectory scan problems

Hi,

We are getting a segmentation fault error when running the IOC with the pmacControllerTrajectory.template. Using gdb debugger we realized that profileUser_ and profileVelMode_ pointer were not initialized and the free() functions at lines 2416 and 2421 of pmacController.cpp, respectively, probably deallocates forbidden memory region causing the problem. We could not find errors on our setup so we initialized those variables as NULL at constructor pmacController::pmacController at lines 223, 224 and 225:

// Initialize pointer values as NULL
profileUser_=NULL;
profileVelMode=NULL;

Have we forget some initial configuration or is this a bug?

Another problem we are facing is that most of the times pointer can not return to buffer A after finishing buffer B at first cycle:

Buffer A -> Buffer B -> Stop here.

The GUI shows this failure immediately after I press Execute Profile. We generated 6000 points but we are using just 2500 to debug this buffer change problem.

I had to change manually the Version inside PowerPMAC to 2.0 in order to fix the incompatibility. I could not find an updated version of motion program (compatible with driver 2.0) here: trajectory_scan_code_ppmac.pmc and here trajectory_scan_definitions_ppmac.pmh.

Thanks
George