Gregs

I think what you might want is to just start the second program with a command to move X to the actual position, i.e. X(Motor(x).ActPos).

Can you send a screenshot of the motor setup window showing all of the settings?

Thanks for the correction. Note that I went back and edited to make the correction.

A user shared memory address could be used to hold the value of Acc84E[0].Chan[0].SerialEncDataB, and then individual bits in the user shared memory addresses could be accessed. For example: u.user:$3000 = Acc84E[0].Chan[0].SerialEncDataB ptr LENC1CRC->u.user:$3000.4.1 // for reading bit 4 See under the headings User Shared Memory Buffer Variables and M-Variable Access in the Power PMAC Users manual for details.

Beyond selecting the correct topology blocks for the type of motor and encoder, hardware parameters have to be set based on motor specifications etc. You will need to select or add a correct database file in System Setup. Direct microstepping is used with stepper motors. Is this a stepper motor? Try following System Setup instructions in the IDE manual, particularly under the "MOTOR SETUP" heading. The IDE manual is accessible under the Help tab. I still have IDE 4.6.0.14, still pretty new and works well. I don't think it has anything to do with your situation.

You might look into something like the OMRON NB3Q-TW01B-V1 touch screen HMI for OEM with 3.5-inch TFT color LCD display, ModBUS TCP. Looking at products on the website, I think that's the lowest cost solution of that variety. Contact ODT tech support for details.

PEWIN32 Pro would have been installed and licensed using a CD that came with the purchase of the software. A CD and and associated license key is needed for reinstallation. Communication drivers are loaded with the installation and are probably needed by the GUI. The Pro version can no longer be purchased. The Pro2 version is still available for purchase, and it can be downloaded and installed for free, which will install the communication drivers; however, they are not compatible with the Pro drivers. The only solution might be to have the GUI recoded for using the new communication library.

The ACC-24E3 manual has a section under the heading Pulse-and-Direction Amplifiers which applies as well to the CK3W-1414x or CK3W-1515x. Gain values for simulated loop are given as follows: It is recommended that the following servo gain values be used to close a simulated loop: · Motor[x].Servo.Kp = 40 · Motor[x].Servo.Kvfb = 0 · Motor[x].Servo.Kvff = 40 · Motor[x].Servo.Ki = 0.001 Many users will want to create a half count of deadband in the servo loop to prevent dithering between adjacent steps at rest if the command value stopped in between them. To do this, set Motor[x].BreakPosErr to 0.5 (if the motor units are equal to pulses), and Motor[x].Kbreak to 0.0. For more extensive information, see in the Power PMAC Users manual under the heading Setting Up Power PMAC for Pulse-and-Direction Control. Similar to above, it states: Parameters to Set Up Motor Servo Gains If you are using a real feedback sensor, the motor’s servo loop should be tuned just as a normal servo motor would be. This is covered in a later section of the manual. However, if you are just using the counted pulse train for feedback to create a fully electronic loop, the response is very predictable, and the tuning gains can be set directly. The following values provide a responsive and stable performance at the default servo update frequency for a motor scaled in units of pulses (counts): (Same settings as above)

I'm not sure what you mean when saying "the executor does not respond". Is the right coordinate system being addressed? Why is s1 being assigned to coordinate system 0? Is it a virtual axis? Note the following, copied from the Users manual: In many applications, some of the data structures with index value of 0 will not be used. Servo hardware interface channels are auto-assigned to motors and encoder conversion table entries starting with index values of 1. Coordinate System 0 is typically used just to “park” motors that have not been assigned to axes in an active coordinate system.

I believe this is the “expected” PMAC result to a full rotary buffer. The gpascii thread will “process” no more commands until the buffer is freed up. But, PMAC will continue to “queue up” characters into the communication buffer for that thread. Other threads will work OK. Note that each instance of a “command()” is a separate communication thread.

The following was copied from the Power PMAC Users manual: Rotary Motion Programs The rules governing rotary motion program buffers are substantially different from those for the other types of Script program buffers. A pre-determined amount of memory must be reserved for a rotary buffer before any contents are downloaded. Program lines can be entered into the buffer even while the program is executing. When the end of the buffer is reached, the storage of subsequent program lines wraps around to the beginning of the buffer – hence the name “rotary”.

This is not the venue for technical support issues. Please contact ODT-Support@omron.com for US domestic technical support issues. Otherwise, please contact your local Omron Technical Center for any technical support as they should be your primary choice. They can “escalate” any issues back to the US domestic group if needed. This provides for better visibility within the Omron organization. This will also be more timely being in a “closer” time zone: You can always send inquiries to Omron Global support at "ia.techsupport@omron.com". Make certain to have “Delta Tau” or “PMAC” clearly in the subject line for proper “group” routing. If they are unable to provide support then please contact US Domestic support (ODT-Support@omron.com) directly. Also, note that this is regarding a Power PMAC, so should it should have been posted in the Power, not Turbo section.

See the attached document. Note that I did some testing with that procedure, and I had some trouble when I ran the PLC again with the axis in different positions. There was a problem with the stored home position. I remedied that with some code that used the HomeOffset to compensate for the last stored home position. The code I added is in the two commented out sections here: open plc Mot5AbsPos LOCAL Direction //Is the drive set as CW+ or CCW+ /* local OldHomePos, HomePosDiff, HomeOffsetSetting HomeOffsetSetting=Motor[5].HomeOffset // Store HomeOffset Motor[5].HomeOffset=0 OldHomePos=Motor[5].HomePos */ Sys.Udata[13] = ecattypedsdo(0,0,1,$4510,$84,0,$4) sys.Idata[14] = ecattypedsdo(0,0,1,$4510,$85,0,$4) Direction = ecattypedsdo(0,0,1,$3000,1,0,4) CALL Timer(0.050) Motor[5].AbsPosSf = ((2 * Direction) - 1) * Motor[5].PosSf CALL Timer(0.050) HOMEZ 5 /* CALL Timer(0.050) Motor[5].HomeOffset = HomeOffsetSetting + OldHomePos - Motor[5].HomePos // Restore HomeOffset and add in the change in HomePos HOMEZ 5 CALL Timer(0.050) Motor[5].HomeOffset = HomeOffsetSetting // Restore proper setting */ DISABLE PLC Mot5AbsPos CLOSE Absolute Homing a 1S Drive over EtherCAT.pdf

That sounds like a programming issue for which Flow should be contacted for help. That being said, if the old card can be connected to, as directed by Steve above, the configurations could be compared to see what might be the problem.

That error is reporting that you typed ecat "3", not ecat reset. It would seem that somewhere in the project there is a #define statement defining reset as "3", i.e. #define reset 3. I would look in Global Includes first. Or, ctrl-F to search in the project.

I was just talking about how the errors are listed in the error description document, but now that you mention it, I should have said that the 981 is always used (or added), not dropped as shown in the document.

As for ECAT[i].Error, it will report errors while EtherCAT is activated, and I believe that the 981 is always dropped for purpose of looking up the error in the documentation.

We might learn something by monitoring the serial port. It seems like something is messing with PMAC's memory.

The full code is $9811000A, i.e. the "981" is dropped in that response. So, in the table, $1000a is given as 0x9811000A EC_E_NOMEMORY Not enough allocatable memory available (memory full / corrupted). I attached a more detailed list. EcMaster_31103 ErrorCodes 1.pdf

This could be caused by a firewall or some other port blocking administration. Can you try another computer?

Not specifically, but see in the Power PMAC Users manual under the heading Setting Up Serial Encoders.

See in the Power PMAC Users manual under the headings "Digital I/O Hardware and Configuration" and "Setting Up Parallel Data Position Inputs".

Thanks Alex. One more thought, another approach could be to process the value as an entry in the encoder conversion table, for example with settings like this: Sys.Udata[]=32768 EncTable[].pEnc=Ecat [i]. io [j]. Data EncTable[].pEnc1=Sys.Udata[] EncTable[].type=9

What should be done depends on what's happening. Analog Voltage PMAC Reading (Shift by 32k) PMAC Reading (Read as Signed) -10V 0 32768 -5V 16384 49152 0V 32768 0 5V 49152 16384 10V 65536 32767 It's possible that PMAC is reading the correct data, but then just shifting it by 32384, and in that case, subtract and scale. A PLC like this could be used: GLOBAL AnalogIn OPEN PLC AnalogReadPLC AnalogIn = (SensorValue - 32768)/3276.8 // divide by 3276.8 to convert to volts CLOSE It's also possible that the data is signed, but the ESI file is telling PMAC to read it as unsigned, so the fix is to read it as signed. In that case, writing it into UData, then reading it out of Idata may fix it. To do that one, you'd need a PLC like: GLOBAL AnalogIn OPEN PLC AnalogReadPLC Sys.Udata[10] = SensorValue AnalogIn = Sys.Idata[10]/3276.8 CLOSE So, from just "it's showing 0-65k", that's not enough info to determine how to fix it. We'd need to know when it shows 0, and when it shows 65k.

That means there's an issue in the project such as an undeclared variable or syntax problem. There should be more information on the error in the Output tab. If help is still needed, please contact ODT's direct tech support with your full issue details at ODT-Support@Omron.com.