Eric Hotchkiss

Is there a reason you need to programmatically perform an ecat reset (or ethercat rescan) before mapping PDOs? Normally we would save the project with this already done. Perhaps you mean enable ethercat with ECAT[0].Enable=1 and you just want to make sure the network is present first?

I'm attaching our absolute position read slides. They go over doing the read (from hmz or power up with PowerOnMode set), but not the actual gate serial settings (SerialEncCmd). If you move the motor by hand, does it seem to move by the appropriate number of motor units? If so, you probably have the correct value of Motor[x].PosSf and Motor[x].Pos2Sf. As well as ongoing position setup in general. If that is correct, take a look at Motor[x].AbsPosSf, this should match Motor[x].PosSf. I am still skeptical of Motor[4].AbsPosFormat, but it sounds like changing it does not fix your problem. You could also check the value of PowerBrick[0].Chan[2].SerialEncDataA and see if this is the position data you expect (position bits can change by rotating the motor). Serial On-Going Position.pdf Absolute Position Read.pdf

It sounds like your new IDE did not install correctly. Please try to uninstall and reinstall. You may want to check your antivirus/firewall or talk to your IT department.

What do you mean by capture position? I feel like I was misunderstanding your question. Looking back over, it sounds like you just mean the position displayed in the IDE after a $$$ or #4hmz. Is this correct? Maybe the HomePos value is changing, but the real question is why does my position look like nonsense after a $$$ or #4hmz? This could easily mean the scale factors for ongoing vs power up positions don't match or a number of settings. I'd like to start with Motor[4].AbsPosFormat Motor[4].AbsPosFormat looks a little funny. We normally say Motor[4].AbsPosFormat=$AABBCCDD and look at each byte individually Motor[4].AbsPosFormat=$72001907 DD=$07=7 Read from first register starting at bit 7 CC=$19=25 Read a total of 25 bits BB=$00=0 When reading remaining bits from second register, start at bit 0 AA=$72=114 Use a format of ???? AA should be 0-3 for signed/unsigned binary/grey code.

Even for an absolute serial encoder, your position comes from two sources. Motor[x].Pos/ActPos is created by looking at the change in the number Enctable[n].pEnc points at since PMAC starts up (or since Motor[x].ServoCtrl was set =1). This is purely incremental and ignores the value on startup. Homez/HMZ, reading the absolute encoder to set Motor[x].HomePos.

Motor position variables tend to be position relative to the Motor's power on position. This is true for at least Motor[x].Pos, Motor[x].ActPos, Motor[x].DesPos. To get the (compensated encoder) position relative to home, you would take Motor[x].ActPos-Motor[x].HomePos. On a HOMEZ or HMZ, PMAC does not change the value of Motor[x].ActPos, but instead changes Motor[x].HomePos based on the captured absolute position so that Motor[x].ActPos-Motor[x].HomePos is your captured absolute position. This means the Captured position should change and HomePos should be the power on position.

Is this on Acontis or Etherlabs?

I can't compile with the name GetTimeOfDay(), but I am able to run a bgcplc 0 with only "pshm->P[0]=GetPMACTimeOfDay();" for contents on an otherwise empty 465 CPU running firmware 2.5. Do the freezes only show up in IDE communication? At default settings this seems to increase my background CPU load by about 20%. What is your CPU load like? Perhaps adding a delay in the bgcplc or increasing Sys.BgSleepTime could help resolve the issue.

Do you have any antivirus/firewall running during install that could block something?

example: list prog 1

Target torque is the output of our servo loop. The numbers you mention for target torque are probably close to Following Error * Motor[x].Servo.Kp.Target torque will be saturated at a value of Motor[x].MaxDac. You would need information from the drive manufacturer to find out how much current target torque of 1000 is.

The only answer I was able to get was asynchronous maintenance packets and that if you did send SDOs they would most likely be in those packets. I also want to point out that they have a period of 10 ms, where the larger ones had a period of 1 ms.

Yes, we have training slides containing C Programming information here: http://forums.deltatau.com/filedepot/download.php?f=Power%20PMAC/Training%20Slides/Class%20Slides/Power%20PMAC%205-Day%20Training%20-%20December%202016.pdf [FILE REMOVED] Slide 468 for C Programming Slide 535 for CfromScript And here: http://forums.deltatau.com/filedepot/download.php?f=Power%20PMAC/Training%20Slides/Reference%20Slides/20-Power%20PMAC%20C%20Programs%202013-12.ppt [FILE REMOVED] Slide 21 for CfromScript I would suggest the first one as it is newer and more detailed.

Hi Dave, It does look like the size 64 packets have a period of 10 ms. It's possible that they are from SDOs called either in a PLC or the watch window (if you lowered the default period). Maybe you have a 10 ms timer in a PLC. Try disabling PLCs are seeing if it goes away. It is also possible that they could be from transfers to devices in freerun mode. Is this all Elmo drives or do you have any IO devices in your network?

I don't think I can comment on the forum post, but it might work. A couple ideas: 1. If you want to drag the program into the terminal, but don't want to manually replace variables, you can issue "list prog name" or "list plc name" to get the program, modify it and then drag it back into the terminal. 2. After a build and download all (save and $$$ would require another) you can right click on individual script files not in the global includes folder and select "Download Selected Files". This will also re-download all files in global includes. The linked post seemed to be saying this had problems in the past.

The IDE Manual for your IDE version is currently included in your IDE under: Help -> PowerPMAC IDE Manual This will open it in a PDF viewer. You can use save as to put a copy in a convenient location.

We have an example in this App note. http://forums.deltatau.com/filedepot/download.php?f=Power%20PMAC/Application%20Notes/Saving%20Files%20on%20Power%20PMAC%20or%20External%20Media.pdf [FILE REMOVED] Look at the "Saving Files on External Flash Devices" section starting on page 3. At one point the app note instructs you to connect over telnet by typing a command windows command. I would suggest connecting with SSH through putty instead. Telnet may be disabled on newer form factors with the expectation that SSH will be used instead.

Startup PLC's would be enabled in pp_startup.txt with a line like "Enable PLC InitializePlc". pp_startup.txt should run on build and download. I just did a test on a CK3E with firmware 2.5 and it runs (just set a P Variable).

I believe I gave an incomplete answer before. The intended behavior is that is Motor[x].PosSf=1, you can put any number you want in the box. If PosSf != 1, then the box is grayed out and displays 1/Motor[x].PosSf. If this is the case, motor units will be displayed. In previous IDE versions, the box could be grayed out accidentally, so make sure you are on at least version 4.2.1.19.

It looks like the PMATCH works a little funny with the dry run filter. The filter works by allowing Motor[3].Desired.Pos to change and track the program position, while Motor[3].DesPos stays constant so that PMAC does not move the motor. PMATCH grabs the motor's true position from Motor[3].DesPos. The next program line with a move has an implicit move to this current position. Now the program thinks it's moving from the axis position Motor[3].Desired.Pos (which was tracking the program) to the position the actual motor is locked at Motor[3].DesPos in a single segment (Coord[x].SegMoveTime). Lookahead then greatly stretches the move time for the locked axis. This extends the move time for all motors to keep positions synced up. To solve this problem we can issue Motor[3].Desired.Pos=Motor[3].DesPos before PMATCH, if the dry run filter is active. It looks like you have 2 PMATCH statements, one in the ComputeNCTransform(XformNum) subprogram and one in G511, which runs after the dry run filter is disabled. We can ignore G511. In the sub program, we want a block like this: DWELL 0 Motor[3].Desired.Pos=Motor[3].DesPos PMATCH DWELL 0 Using this method may increase or decrease the time that PMAC is waiting for the locked motor in the first move after the PMATCH, as it is changing the axis level starting position and thus travel distance.

In theory, this would be done either with "EncTable[2].pEnc=EncTable[1].DeltaPos.a" or "EncTable[2].pEnc=Motor[1].FltrVel.a". However, either of these will throw a "error #70: Struct Write Data Error". If you wanted to force this method to work, you could repeat Motor[1].FltrVel into Sys.Udata in a custom servo algorithm so that on the next pass through the ECT the value is available. Set Enctable[n].pEnc=Sys.Udata.a to read the copied FltrVel. If you do the calculations in C they should be about the same as the ECT, where script would be a little slower. We sell the ACC-24E3 with two sinusoidal interpolator options; standard and auto-correcting. The velocity and acceleration data require the auto-correcting option.

I'm a little confused. I can't set write to EncTable [16].DeltaPos, are you setting: Enctable[16].pEnc=Enctable[13].PrevEnc and changing Enctable[16].ScaleFactor with varOverraid?

Is there a reason you would want to mix feedrate override with external time base? The whole point of external time base would be to go at the same speed an the encoder. I'd assume you'd want to slow down the motor that is the time base master, not the slave coordinate system. Normally feedrate override is accomplished by changing Coord[x].DesTimeBase so that Coord[x].TimeBase changes based on Coord[x].TimeBaseSlew. When using external time base, Coord[x].DesTimeBase will still change from %n, but it will have no affect on Coord[x].TimeBase as it is set based on encoder velocity. We can probably still make this happen if an extra ECT entry is used to multiply in Coord[x].DesTimeBase. Although this would probably require a RTI PLC or servo algorithm to repeated values from Coord[x].DesTimeBase to Sys.Idata[] where the ECT can actually point. This strategy would ignore Coord[x].TimeBaseSlew.

We can use the ECT to get a first derivative, velocity. This would be done by reading Enctable[n].DeltaPos in your own program. However, there is no way to take further derivatives without using some tricks. Basically you can get velocity from Enctable[n].DeltaPos, Motor[x].ActVel, or Motor[x].FltrVel. Out of these Motor[x].FltrVel has the least noise because it is based on the current position and the position 16 cycles ago. This also means it's really a best guess of the velocity 8 servo cycles ago. To get motor units per millisecond you can use Motor[x].FltrVel/(16*Sys.ServoPeriod). If you calculate acceleration and jerk from Motor[x].FltrVel, then hopefully you can get a little less noise. On the additional data request question, are you using an autocorrecting interpolator?

None of the settings in the ethercat folder should take affect until you select "Load Mapping To PowerPmac". I am attempting to answer the timeout questions in the other thread.