Sanjay_RSS

I'm on the latest as far as I know .. 2.7.1.0 and also using latest PowerPmacIDE .. version 4.6.2.15

No .. I often see other $98xxxxxx errors in the Ecat[i].Error register. As far as I can remember, the $1000A is the only error where the $981 is trimmed out

Further troubleshooting confirmed that the issue was the cutter-comp-radius commands creating a momentary blip while doing the initial pre-calculations when a ccmode1 / ccmode2 statement is encountered. Our normal settings have been Coord[x].CCSize = 20 and Coord[x].CCDistance = 10 .. which basically means that up to 10 upcoming moves would be scanned to check for interference and blend the appropriate tool path adjustments for the upcoming moves. However, it seems that the algorithm for doing these calculations are not multi-threaded much as it seems to take over the CPU and until the CCR calculations are done, ethercat packets are not being processed. This in turn triggers the big spike in Ecat[x].DcClockDiff and then eventually the $1000A appears. I was able to lower my Coord[x].CCDistance to 4 and saw the spike diminish substantially back down to normal "background" deviations and now my Ethercat seems more stable. BTW, This is all on the latest firmware version 2.7.1.0 although I have also seen it on 2.7.0.0 .. not sure about the earlier firmwares. Could the firmware team check into the cutter-comp functions and see if they can be properly multi-threaded so that the Ethercat logic also gets a chance to run as needed during the calculations ? Also, I'm thinking there is some way that the CCR logic is also corrupting or filling up the same buffer that Acontis stack is trying to use which then triggers the EC_E_NOMEMORY error...

I'm seeing this $1000A error popping up in my CK3M system as well. It seems to be somehow correleated with cutter-comp being turned on. Right after a "ccmode1" or "ccmode2" in a program, the Ecat[0].DcClockDiff jumps to a very large time (bigger than my Sys.ServoPeriod) and then is pulled back to the normal band via the Ecat[0].DcRefPlus & Ecat[0].DcRefMinus After a few of these spikes, I end up seeing this $1000A in the Ecat[0].Error register even though everything else seems to be functioning normally.. and all the other Ecat error / status registers are mostly normal. I do see a bit wierd status (Ecat[0].Status[0]) value of $2000200 .. which is bit 25 & bit 9 on. As per the PowerPMAC manual, bit 25 is ReserveErr10 and bit 9 = FrameResponseErr .. Also, I see the Ecat[0].MaxSemTime rise to 480 - 520 usec (typically its around 40-50 usec max). Any idea why turning on cutter-comp would trigger a spike in the Ecat clock and how to prevent it?

Are you using the NETC01-ECT ethercat gateway or a different model drive with the built-in Ethercat? We have mostly just used the gateway and not seen much of an issue. Perhaps try connecting the Oriental drive as the only node in your ethercat network with the CK3E until you get the issues figured out and then connect back the other nodes.. Also, confirm that you are plugging the cable into the correct "IN" port (should be the top port).

Any update on the new IDE release timeframes?

Is anyone else seeing a CPU leak when using the Power PMAC IDE versions 4.6.0 and 4.6.1 Motor Definition screens? I seem to be able to trigger the issue everytime I go into the new Motor Definition screen's Commission screen and then open up the Advanced section and pick any category in the drop-down except for the original Addressing. As soon as you do this, the CPU seems to go into some kind of infinite loop behavior and the IDE will jump from using 5-15% of my CPU to about 25-35%. Then, each time, you pick a new category from the dropdown, CPU usage will jump by another 25% until it is using 95-99% of my CPU in the task manager and then continue with that behavior even if the motor definition screens are closed. The only way to reset back to normal is to close the entire IDE application and restart. If you don't do this, with the CPU pegged at 95-99%, all the rest of the IDE functions and other Windows programs are basically getting starved and operate incredibly slowly.. I have checked and the cpu runaway behavior is there even if not connected to a controller. Just picking different categories in that Advanced section drop-down is enough to trigger the runaway behavior. Also, it doesn't matter if motor is analog or ethercat template.. The "legacy" tuning screens are still available in the latest 4.6 versions .. is there any option to enable "legacy" motor definition screens? The rest of the IDE seems to work well but it was definitely much easier to setup a motor on the "legacy" version compared to now. I've got a screen recording attached showing the issue. Keep an eye on the task manager in the right corner. Is there any even more updated version of the IDE that has this resolved? PowerPmac IDE CPU bug.mp4

I believe Ignition has drivers for Modbus TCP which can be an easy way to interface with PowerPMAC. https://docs.inductiveautomation.com/display/DOC81/Modbus The PowerPMAC docs are under the sample project PowerPMACModbusExample installed by the IDE

For anyone awaiting it, the new 4.6.0.14 version of the IDE has been posted to the main Omron PowerPMAC IDE webpage.

Thank you Eric.

Is there any app-note or example source code, etc. to understand better how to configure some drives in a hot-connect group and be able to power them off / on without killing the rest of the Ethercat network? I see very brief mentions of stuff in the Power PMAC IDE manual but not really anything in detail.

You could use the home-offset parameter to change the "zero" as compared to the home-position. Lookup Motor[x].HomeOffset in the SRM for the details.

I'm seeing references on the Omron website on the Power PMAC IDE page to a new IDE version 4.6.0.14 released back in May .. there are software release notes as well as some "Product News" / "Power PMAC IDE Modification Notice" .. but don't see the actual IDE version there to be downloaded. Is there some alternate place to download the new version from?

As I mentioned, try editing the ESI file and mark the entries as signed instead of unsigned.

Hi Steve, Did this serial number lookup page ever get moved to somewhere on the Omron website? It made it easier to check for revision model numbers on sub-assemblies.