HJTrost

My problem is that after loading a bunch of settings (Clipper[0]...., Motor[x]...., Coord[1]...., EncTable[n]....) through a .pmh file of mine in the Global Includes directory into my Power PMAC Clipper, and then entering a command #1j=100000 in the Terminal window of the Power PMAC IDE gives me a move that is not commensurate with my hardware parameters, i.e., the 100000 counts do not make for a 75 mm move. My hardware has a lead screw of 6 mm/rev, and the rotary motor has a rotary encoder on it with 2000 lines or 8000 quadrature counts per rev. My coordinate system definition is &1 #1->x #2->y #3->z and I want to move in units of encoder counts or LSBs. But only if I set EncTable[n].ScaleFactor=1/813 do I get about 75 mm for my 100000 "counts" move. My encoder conversion tables look like this: EncTable[1].Type=1 EncTable[1].pEnc=Clipper[0].Chan[0].TimerA.a EncTable[1].index1=0 EncTable[1].index2=0 EncTable[1].ScaleFactor=1/813 // EncTable[1].ScaleFactor=1/256 following the description on pages 71ff in the Power PMAC Clipper manual of August 21, 2021. I just noticed that on p.31, ServoCapt.a is offered for setting up quadrature encoders rather than TimerA.a - I'll try that one this afternoon. It is not obvious to me which one of those is "right" for what reason.

Thanks for clarifying the relationships. By setting EncTable[x].ScaleFactor=1/813.0 I am now getting my 75 mm for 100,000 encoder counts. For now, I can live with handling the encoder scale this way. Still, I don't understand why the raw quadrature encoder counts, which are unambiguously defined in hardware, are not being made available without any hidden scaling. After all, that factor 1/813 has its own uncertainty, which comes on top of the one in the hardware (the accuracy of the linearity is somewhere in the 100-150 micron range in my present test system), and which I will have to measure eventually.

I now have got my Power PMAC 465 Clipper to move my stages smoothly, with one odd feature: I have rotary encoders on the motors of my leadscrew stages with 2000 lines per rev, corresponding to 6 mm/rev of the screw. However, the counts reported by the Power PMAC are off by a factor 3.125 - 100,000 quadrature counts are reported at 24 mm instead of 75 mm. Motor[x].PosSf and its relatives are all set to 1.0. From using other controllers (PMAC2A/PC104, Turbo Clipper) on the same system I positively know that 75 mm is the correct answer. Are there any candidates among the many parameters that could be "used" to create such a discrepancy? Cheers, Jochen

Steve, thanks for being patient with me. I have no problem sticking to 4.4.0.99 until I get the firmware update (I've asked our local distributor and Omron rep for it.) I'm running right now with only one motor (no.1), until I get it going. I still doubt that it is the tuning: 1. The motor does not respond to setting Motor[1].ServoCtrl=0. 2. The motor does not respond to setting Kp=Ki=0 in the Motor[1].Servo block. If I do that with a Turbo Clipper or PMAC2A/PC104, the motor gets stopped and held in place. We use this setting to prevent vibrations induced by the motor slightly hunting, which occurs on some of our machines, and there are situations where we absolutely have to avoid that. I also doubt that it is the drive or motor or anything downstream from the JMACH1 and JMACH2 connectors, because I can hook the 50-wire ribbon and 34-wire ribbon to my old PMAC2A/PC104 and it works flawlessly. I'll take this one over to ODT-Support as you suggested. Cheers, Jochen

I downgraded the IDE from 4.6.0.14 to 4.4.0.99 and got rid of the message about Coord[1].SignIsDirType that way. I still don't see where to look why the PowerPMAC makes my motors drift away while the PMAC2A/PC104 controls them just fine.

I'm still looking why my motors creep on their own. I commented a few settings related to the PFM clock frequency, did a Build and Download, and got a new error: C:\DeltaTau\PowerPMAC3\Configuration\systemsetup.cfg(796,1) : Error : ( error #20) ILLEGAL CMD : Coord[1].SignIsDirType=0 I walked my changes back, Build and Download again, and the new error is staying there. Where does it come from? The manual says this parameter is new with Firmware version2.6 - I have 2.5.0.4 (and IDE 4.6.0.14). Did the IDE update itself silently?

Okay, picking "Torque" got me through to the "Test and Set" step. The test fails, and my motors still do their slow creep, moving their stages towards one end. The troubleshooter for "Why is my motor moving slowly?" is happy with all parameters it shows. I don't have any limit switches but PowerClipper complains about both positive and negative overtravel limits being flagged. It also complains about amplifier faults, although that maybe a polarity issue in my hardware. For a test, I have swapped in a PMAC2A/PC104 (I don't have a Turbo Clipper on hand; the programs are the same between the Clipper and the PC104 to the extent they can be), and the stages behave all around. So what could still be wrong?

I am trying to convert from a Turbo PMAC2 Clipper to a PowerPMAC 465 Clipper (as a current stand-in for a CK3C AX1100 Clipper, which is to replace the Turbo Clipper for us). I have cut the Turbo program down to 3 small PLCs, a macro definition file and a machine-specific paramweter definition file. My hardware downstream from the Clipper consists of 3 leadscrew stages with stepper motor (Schneider M-2218-3.0) and amplifier (IMS IM483H Plus), with rotary encoders on the motors (2000 lines/rev, quadrature). With no other custom additions to my PowerPMAC project, I can can build and download into my Power Clipper seemingly without errors. However, when I power up the amplifers and motors, they ignore what I have in my project and all three just creep slowly towards one end of their motion range. They even ignore the setting Motor[x].ServoCtrl=0 So I started to tell the IDE project about the hardware and defined the amplifer, motor and encoder with the corresponding part managers. The amplifier is accepted without complaint, but the IDE does not like to add my motor to the configuration, saying A stepper motor can only be configured as high pole-pair brushless using the BrickLV amplifier. I have attached the topology display with the error message and my amplifier and motor definitons in their parts manager displays, and also (substantially trimmed) the machine-specific parameter file. What am I missing or doing wrong? PTDEV.30.00_snipped.pmh

Gregs, thanks a lot for the suggestions. You are right on both "p63" and "MotorMode". I will check the pPhaseEnc tomorrow but expect that you got that one right, too. Jochen

I have made my first download attempts with my Power PMAC Clipper and am encountering a few strange errors in setting up my motors. The attached file shows the complete list that I want to use. There are issues with three of the parameters; they are commented out in the file. When I activate them (one at a time), I get the following error messages: Motor[1].JogSpeed=6.6666 C:\DeltaTau\PowerPMAC2\PowerPMAC2\PMAC Script Language\Global Includes\PTDEV.30.00.pmh(430,1) : Error : ( error #21) ILLEGAL PARAMETER : Motor[1].p63=6.66666 Motor[1].MotorNode=0 C:\DeltaTau\PowerPMAC2\PowerPMAC2\PMAC Script Language\Global Includes\PTDEV.30.00.pmh(475,1) : Error : ( error #21) ILLEGAL PARAMETER : Motor[1].MotorNode=0 Motor[1].pPhaseEnc=0 C:\DeltaTau\PowerPMAC2\PowerPMAC2\PMAC Script Language\Global Includes\PTDEV.30.00.pmh(501,20) : Error : ( error #70) Struct Write Data Error : Motor[1].pPhaseEnc=0 The motor settings reside in a global include file (,pmh) that is designed to be the only machine-specific file in my whole program package for the controller. What is wrong with these parameters? Jochen Motor1Setup.txt

The problem is apparently more fundamental. Do the following in the Power PMAC IDE on your host computer: Start Power PMAC IDE 4. Tell it there is no device. Click on File -> New -> Project... In the New Project pop-up, select "PowerPMAC with Ethernet/IP", set a "Name", e.g., "PowerPMAC5", and click on "OK". Click on Build -> Build Solution. The following will appear on the Output tab: ------ Build started: Project: PowerPMAC5, Configuration: Debug Any CPU ------ Please wait while Executing Project Script. Please wait while mapping Power PMAC variables. End of synchronizing the Database. Power PMAC variables mapped successfully. Error occurred while building. Project Building and Mapping total time = 4.811 sec ========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ========== In the Solution Explorer window, expand "C Language", then "Include", and click on "pp_proj.h". This file will be displayed in the source window and as soon as you start to scroll down through it, the red marks for errors show up, with the errors saying #define directive XXXXXXXXXXX is already defined in the file pp_proj.h There are 36 of these, and there are also 12 warnings saying Variable YYYYYYYYYY is already defined in this scope. These warnings have also been seen by other people, like here: https://forums.automation.omron.com/topic/6347-unable-to-navigate-to-error/#comment-27257 I have originally used the IDE version 4.5.2.9 and am using now (freshly downloaded today) 4.6.0.14. The update made no difference whatsoever. What do I need to do to get around these bugs?

I am trying to set up a project in Power Pmac IDE in preparing to migrate from Turbo Clipper to Power Clipper controllers. I have let the Power Pmac IDE set up a basic project, adding 2 .pmh files with parameter settings and preprocessor macro definitions and three script PLCs. I am still telling the IDE that there is no device and them build the solution anyway so I can weed out bugs. The IDE has taken my pmh files and loaded pp_proj.h in the "C Language\Include" directory with definitions derived from mine, and then turns around to say that there are errors galore of the type #define directive XXXXXXXX is already defined in the file pp_proj. Some of the XXXXXXX are taken from my #define statements like #define PValWrite p601 and are transformed into #define PValWrite pshm->P[601] enum globalP { ... ,PValWrite=601, ... #define PValWrite 601 where these three are weaved into a modestly complex #if #else #if #else #endif #endif like structure such that only one of the should be alive under any circumstance. I also get multiple declarations of functions that I did not knowingly ask for anywhere void SetEnumGlobalVar(enum globalP var, double data) This also appears three times wedged into the same #if #else #endif structure. I have manually parsed the pp_proj.h file and don't understand where the claim of duplication comes from. The full structure is outlined in the attached file. IDE-Bugstructure.txt

I don't have my trial project (setting of variables, macro definitions and 3 basic PLCs out of my Turbo program conversion) far enough to actually hook up to my controller, so it will be a while until I get to see the Ldata.CmdStatus. pp_proj.h gets loaded with errors, creating among other issues somehow duplicates from definitions in my .pmh files. I'll take that into a new thread next week. Thanks for your guidance so far.

Thanks for pointing me in the right direction. An apparent disadvantage is that this requires shipping the original source files (.pmc) for field updates rather than the single .56K.

Thanks for the advice, that will work. I was going to write instead if (Motor[1].PlusLimit || Motor[1].SoftPlusLimit) p80 = 1 ; else p80 = 0 ;

What is not to like about this PLC: open plc Myplc1 p80 = Motor[1].PlusLimit || Motor[1].SoftPlusLimit ; p81 = Motor[1].PlusLimit || Motor[1].SoftPlusLimit ; close The first double-bar draws the error message, the second does only if I remove the first one. PlusLimit and SoftPlusLimit are advertised as Booleans in the Power Pmac SRM.

Dave, unfortunately not. The error message disappears alright, but when I write cmd "CmdPhaseXYZ"; into the PLC, with no definition of CmdPhaseXYZ anywhere, there is no error message either.

Good question. One of my .pmh files contains these lines: &1 #1->x #2->y #3->Z &3 #4->W &4 #5->C Putting the coordinate system explicitly into the CmdPhase definitions does not change the error message. Putting the actual command in place of the macro instruction makes the error go away. By the way, I am working on a PC and am telling the IDE that there is no device connected. I'm issuing Build commands just to find bugs like this one. The #define is in a .pmh file, the instruction "CmdPhaseX ;" is in a PLC. There are more than one location where these commands are used, which is why I want the macro to ensure that all occurrences use the same command.

I am converting a set of Turbo Pmac programs to Power Pmac in order to make the transition from the Turbo Clipper to the Power Clipper ARM (specifically targeted at the CK3C-AX1100). I noticed that #define's for cmd program commands are not properly recognized, e.g., with #define CmdPhaseX cmd"#1$" I get an error for a line in a PLC CmdPhaseX ; saying "Illegal syntax, expecting type definition or operator". I haven't found any hint in the Power Pmac SRM why the token string cmd"#1$" should be illegal. I'd appreciate any explanation and suggestion. Hans-Jochen Trost

I am still working with PMAC controllers (UMAC, PMAC2-PC104, Turbo Clipper) with our in-house specific software developed under PewinPro. We have some 250 machines in the field. To help customers diagnose occasional problems and installing upgraded versions of our motion software, we have created a small Windows application (Borland C++ Builder 5) that allows sending commands (GetResponseEx), select a controller, and download our precompiled motion software (i.e., a .56K file). For those systems using Windows 7 (64 as well as 32) or older (back to Windows 98 SE) all works well. For the latest machines that use Windows 10, we use the drivers that come with PewinPro2, and we essentially duplicated the small Windows app (MinGW, wxWidgets) on the basis of the corresponding PcommServer instead of going through pcomm32.dll. The single commands work, the controller selection works, but the file download does not. For the file download, I tried calling g_idevice->DownloadFile(device, file) as well as g_idevice->Download(device, file, bmacro, bmap, blog, bdnld, pbsuccess) The program compiles, links and executes without complaint but no trace of the .56K file shows up in the controller. The .56K file is still the one created with Pewin32Pro, not Pewin32Pro2. For now, I take a Windows XP laptop with our original utility app to do the download when readying a machine for shipment. Although updates to our motion program in the controller are very rare, I don't want to rely on our customers being able to also bring in an old PC for just the update exercise. What a I missing to get DownloadFile(...) or Download(...) to do their job? Hans-Jochen Trost

Steve, thanks for the feedback. A replacement card is due in any day. I will test it on an in-house development system (3 stepper motors, laser) and on the real machine (5 servos in a gantry system with 2 of the in the y axis, laser) and let you know what comes out of it. Jochen

I'm using a Turbo PMAC 2 Clipper to operate machines with 3-5 axes. I use the position compare hardware pulses to fire a droplet dispenser or laser during motion. We have almost 20 years practice in our company doing this. I now have for the first time, and only with one Clipper card, seen random noise pulses on an OR of all four EQU lines of the Clipper. They show up whenever they want to, no motion needed. The card has gone back for service, so I don't have any at hand. However, having sorted out all kinds of external causes, I just (re)discovered that on this card, I had set the Position Compare Channel Select I7011 to 1, because the manuals (both PMAC and Turbo PMAC) say it cannot be anything else: "I7m11 performs no effective function, so is always 1. It cannot be set to 0." (I7021, I7031, I7041 and I7111 are all 0.) All other cards we have used have happily lived with 0 for that variable. Because this machine is more complex than all others that we have built, I wanted to make sure that I go strictly by the book. Did I get fooled by a documentation error? Hans-Jochen Trost

Sina, as a belated feedback, that helped and I got my gather project going. Only the "list gather" continued to fail (where does its output go? why does it always give ERR003?) and I abandoned it in favor of writing a custom program to inspect a noncyclic (I45=2) gather buffer in DPRAM after the fact. The noncyclic operation turned out to be sufficient for my purposes. Thanks again, Jochen

Thanks, Sina, that got me over the hump with the DEFINE GATHER. I'm debugging my program right for things that the compilation and download don't notice. I have yet to look at the LIST GATHER which is not in my program but I have tried it in the terminal window with an ERR003 resulting. If that is due to the gather buffer being defined but empty then I should be fine on that count, too. Cheers, Jochen

I think a power cycle is like a $$$ command. Once done, you get all settings as they have been at the last SAVE. So if you want a different setting, do a $$$, make the setting, issue a SAVE, do a $$$ again and see what you've got. You should have what you want now. Cheers, Jochen