dougjr17

Same issue here IDE version 4.5.1.3 -- we narrowed it down to Sync 0 clock signal being missed or delayed past max threshold whenever the PowerPMAC IDE is closed while Ethercat master is enabled, activated and operational. Single AKD slave here running at 4KhZ in torque mode with 2 vars per tx/rx PDOs so not very busy and the timeouts have always been when PowerPMAC IDE crashes or is being closed. CK3M with 1 W module in this case as well.

Any chance these moved to a new address? Bugzilla: https://reporting.deltatau.com/bugzilla/buglist.cgi FTP: ftp.deltatau.com Thanks!!

Are firmware versions now secret since filedepot is gone? How do I know if 2.6.0.0 is latest on a CK3M?

Your address/offset for the digital outputs is wrong. Digital output is a subindex 01 address, not subindex 00, so 0x60FE:01 = correct index for the PDO mapping - you have it as 0x60FE:00 which is not a PDO mappable index, thus correctly resulting in the error indicating illegal address mapping attempted.

It may be helpful to edit the original post in this thread so folks know that the latest IDE download (4.4.0.99) is now only on the Omron Industrial Automation website as of 08/11/2020 (possibly much earlier too): https://automation.omron.com/en/us/products/family/PMAC%20IDE

I may be wrong but you may need to order this SKU: 3A0-9PPRO2-35X Good luck!

Upon boot-up while monitoring terminal output via USB diag RS-232 emulated terminal port, it appears to show some Ethernet/IP initialization status at some point prior to hand-off to where you could login on linux terminal prompt. This would make the CK3E quite an amazing offering - anyone else have any info?

Hi Marcello, I have seen that post a million times before and my guess is the root cause of that specific user's ethernet connectivity stability issue may not be related to use of PEWIN32PRO in Windows 10. I know from experience, for example, that certain Broadcom or Intel NIC drivers had this issue in the past and it was also not Windows 10 specific - just after reaching a specific packet count the network interface would simply not send or receive another packet. If this was really a PEWIN32PRO + Windows 10 = Ethernet unresponsive after 10-15 minutes issue we would have many more complaints here. I would try it out, leave it running 24/7 for a week or two to validate your specific setup and call it a day.

Very interesting - I experienced the exact same issue last year where 2.1.0.39 was the last firmware version I could update the power clipper that originally came with version 1.6.x firmware. After days of building DB9 to special pinout header for serial console connection onto the power clipper, finding the right DHCP/BOOTP utility to offer a lease and boot from TFTP image, then carefully typing in the commands to unprotect the bootloader memory regions that need re-flashing, copying the payload and re-locking down those memory regions, upon reboot it would work and you could use the “firmware in USB media storage under a specially named folder” method to then complete reversing the firmware back to 2.1.0.39. Once you plug that serial console port in and watch the output via putty/terminal connection to it, I suspect you will see that the boot sequence stops right after it enumerates this NOR flash storage where kernel and bootloader reside. For me the boot process halted there in mid sentence and a few minutes later I suspect a watchdog timer would expire and restart the whole cycle. I have a whole folder with all the logs, command sequence and utilities I used to keep reverting back to 2.1.0.39 or earlier. You cannot access to the NOR flash where kernel and bootloader live from the USB connector where you can mount the rest of the PPMAC’s storage when the board if off and you attach that micro-usb connector to a PC. Instead, you need to load the bootloader from TFTP over the network, unprotect/erase the NOR flash storage area for the bootloader and then copy the data obtained via TFTP over Ethernet port. This also obviously requires configuring proper IP address/Ethernet interface settings that will allow you to reach the TFTP host holding the proper bootloader code. Also don’t forget immediately when the board powers on you need to hit space or some other key via putty/serial terminal, like pressing DEL to get into a PC BIOS when it powers up, in order to interrupt the default boot cycle and instead give the board an IP address/subnet mask on same subnet as TFTP/BOOTP hosting machine with bootloader image file resides. Let me know if you still need this and I will dig up that archive - it would take me two days to get it to you.

Is the absence of this feature/console port where we can type commands like on the PowerClipper and interact with u-Boot... why all the CK3E firmware files have been pulled from filedepot so nobody can accidentally brick their units attempting to upgrade firmware themselves when there is no capability for us to self-reflash bootcode?

The above is what may magically happen if you have the perfect Acontis stack supporting PMAC unit with the right firmware and proper IDE version combination, extreme luck and the proper interplanetary alignment of galaxies. Reality is that it took weeks of reading and effort between a CK3E and a PowerClipper unit to connect to Kollmorgan drive and even when it worked, it just released the brake and before I had a chance to send a new value to make motor spin the ethercat bus would time out, IDE would crash and lots of CTRL+ALT+DEL + END-TASKs, service restarts and a few minutes of reloads and reboots later while searching the forum for the 1209421812908 time for anyone else maybe experiencing the same, low and behold a new firmware version is released and the release notes describe issue experienced above as now fixed for acontis stack only when I only had the Etherlab PoweClipper unit. Fast-forward nearly a year and a CK3E now sits on my desk with the proper acontis ethercat stack that is supposed to actually work. Right next to it there is an ethercat Omron NX coupler which I was once able to connect to the other unit that I no longer have access to, but have yet to succeed on CK3E despite following instructions - the NX may not have the right firmware that supports distributed clock = next step to verify on this, meanwhile projects need to move forward and Beckhoff/Siemens/etc just work so that's what gets used since there is only so much time one can invest in the absurd learning curve needed to master the intricacies to get this hardware on ethercat bus up and running. If you are looking for intuitive, easy, reliable, mature or broadly supported I would look elsewhere. Just about a week ago I was looking for firmware updates / checking how CK3E support has progressed since I last touched it nearly a year ago, only to find out all CK3E firmware files have been pulled from the filedepot and to contact support by phone if help needed - in short - the prior transparency with error fixes in release notes and ongoing support progress visibility is now gone and whatever issues I run into I can no longer check if a different firmware version may have resolved. Good luck - I will keep an eye on this thread to see if your ultimate results are better than mine, hopefully that will give me motivation to keep trying on the CK3E and stop using it as a paperweight on my desk reminding me daily to never buy another item like this without first finding a real world customer who successfully implemented same setup I envision for it.

ISSUE 1) Based on README firmware descriptions and given that I have a CK3E unit, one would think that I need to download: powerpmacARM_Posix .. Omron uPower PMAC (CK3E Acontis EtherCAT) but in FILEDEPOT we have all sorts of inconsistent nomenclature except never powerpmacARM_POSIX, so what exactly do I download for a CK3E unit? There is a powerpmacARM download - is that the right one? Here is what README says: Firmware Descriptions powerpmac460ex ...... Power UMAC 460 CPU and Power Brick powerpmac465 ........ Power UMAC/CPCI/Clipper 465 CPU powerpmacARM ........ Power UMAC ARM (hardware not yet released) powerpmacARM_Posix .. Omron uPower PMAC (CK3E Acontis EtherCAT) powerpmacWIN_Posix .. Omron IPC Windows (NY51[]-A Acontis EtherCAT) powerpmacX86_Posix .. Omron IPC Linux (Acontis EtherCAT) Please see the "Release Notes" folder for firmware update information. ISSUE 2) Where are the links for version 2.4.1.x or 2.4.1.2 firmware download? See attached screenshot.

If the Firmware Update/Backup window is off-screen, you can get it back by clicking on Delta-Tau, select the Firmware Update option as usual so it gets activated/focused although you may be unable to see it, press ALT+Space, press M, press any of the arrow keys (up/down/left/right) then move the mouse widely towards either right, left, top or bottom until you begin to see the window again. Hope this helps.

It sounds like you inadvertently downloaded and installed the FULL 3.1.1.0 release package (approximately 2GB) instead of the UPDATE PATCH from 3.1.0.6 to 3.1.1.0 (approximately 40MB) - either that or your prior version was not 3.1.0.6, thus resulting in the experienced request to uninstall prior version during the install process. The UPDATE PATCH can be found here: http://www.deltatau.com/DT_SoftwareDownload/SoftwareUpdates.aspx (second entry - the main download link under Software where you click on a logo/pic to download IDE is the FULL release, not the update patch). Last time I experienced similar botched installation, I ended up manually uninstalling PowerPMAC IDE, PowerPMAC Compiler(s), Acontis EC Tool, MySQL Server 5.0 and WinPCAP in Control Panel, followed by carefully removing original installation paths (after rebooting - some of these will be locked/in-use until you reboot): 1) C:\DeltaTau\ 2) %UserProfile%\AppData\Local\Omron Delta Tau Data Systems\PowerPMAC IDE\3.0 3) %UserProfile%\AppData\Local\Omron_Delta_Tau_Data_Syst (this is not a misspelling - ends with Syst) 4) %UserProfile%\AppData\Roaming\Omron Delta Tau Data Systems\PowerPMAC IDE\3.0 5) %UserProfile%\AppData\Roaming\DeltaTau 6) C:\ProgramData\DeltaTau\PowerPMAC IDE\3\Database 7) %UserProfile%\Documents\Visual Studio 2015 8) Deleted Following Registry Key (and its subkeys): HKEY_CURRENT_USER\Software\Omron Delta Tau Data Systems HKEY_CURRENT_USER\Software\Delta Tau Data Systems Inc Disabling antivirus, ensuring you right-click and run-as-admin, sticking to default installation paths, properly unzipping installation file in a safe local folder (desktop usually works great) prior to installing (and right-clicking/properties + select UNBLOCK to ensure file not marked as unsafe) = winning tips that have previously cost me timeouts or silent abortions during install. Good Luck!

Same here, along with various bus crashes, dropped frames and overall PMAC Clipper non-responsive. Firmware 2.1.0.39 (unable to update Power PMAC Clipper past that version due to boot-up crash). Etherlab stack. CPU command returns PowerPC,APM86xxx Sys.CPUType = 4 Serial C0C0DVG1 Part #4-4050JA0-330-010000 Variant Code 101F Drive I am using is AKD-P00306-NBEC-0069 HW Rev. D with latest AKD Firmware 01-16-00-002 and ESI definition from http://www.kollmorgen.com/en-us/products/drives/servo/akd/_software-firmware/akd-servo-drive-firmware-and-ethercat-device-description-akd-p-nbec-01-16-00-002/ I have been able to get live position updates but still unable to command motor moves under either default startup config from XML (Interpolation Position Mode) nor Cyclic Position or Cyclic Torque modes.

The settings are in pp_startup, so I tried disabling, issuing commands manually, and re-enabling. No difference. This is what I've learned today: Jeff had mentioned earlier today that he had previously had Muxio functioning with 2.0.0.1 firmware. I updated from 1.6.1.1 to 2.0.0.1 and the Muxio immediately started functioning normally. Next I updated from 2.0.0.1 to 2.0.2.14, at it immediately broke. What I'm currently seeing is that inputs are changing, but they are not as expected. As an example, our feedrate override switch is looking at 4 bits of a 32 bit word, in most cases (not all) of changing the switch position, the value changes, but none of the switch positions reflect the correct value. Outputs are now changing state, but outputs that should be unrelated to specific inputs, are turning on/off when the unrelated input changes state. It acts like something has either changed in the addressing or data transfer. I've tried slowing the clock period and Update period way down from your settings, and it seems to have no affect. In case it's of help, in summary the sequence I've been through to break and un-break things: updated from 1.6.1.1 to 2.0.2.14 broke Muxio. reverting back to 1.6.1.1 did not restore to functional. updated from 1.6.1.1 to 2.0.0.1 fixed the problem. updated from 2.0.0.1 to 2.0.2.14 broke it again. Going through the exact same issue as of July 2017 without any accessories, just the PMAC 465 board and now going from 2.0.2.14 to 2.1.0.39

Did you ever end up figuring out if this worked?