Alex Anikstein

For the first screen shot, do you know what would have happened if you had changed the "Search" entry from "VS.Ambient" to something like Motor[x].ServoCtrl? I suppose if you cannot get back to there, it is a moot point, but it might have been helpful for diagnostics. If you type "Motor[x].ServoCtrl" into the Terminal window and then press "F1" key on your keyboard, what happens? When you say the help window does not open, does your computer respond at all? Does anything happen?

As of late 2020, the locations for the firmware and IDE have moved. Previous versions of both are still being kept on the Delta Tau website, available through the for firmware (forums account required) and the Software Center Updates page for software. However, the distribution methods for each have changed for future versions.http://forums.deltatau.com/filedepot/ [FILE REMOVED] Future versions of the IDE are available instead from the Omron Industrial Automation website: https://automation.omron.com/en/us/products/family/PMAC%20IDE Future versions of firmware can typically be distributed directly to customers through Omron Distributors rather than being available for download for anyone. If you need to upgrade the firmware on your unit or obtain a specific other version, contact your Omron Distributor for more information. You may need to provide some information about the product so that the correct file and procedure are provided. These can be obtained by issuing "CPU", "TYPE", and "VERS" into the terminal window, so please be prepared to provide the responses to these commands, too. NOTE: Users have occasionally reported xml errors when attempting to download some of these links. If that occurs, please try again later (these are intermittent issues) or contact your local Omron office and we will try to get you the files another way.

dougjr17, I agree. Since I didn't make the original post I don't really want to edit it, so making a new thread and sticky-ing that one instead. Locking this thread.

Michael, Can you describe more of the problem? When you say it doesn't work, what happens when you hit F1? Do you have any other versions of the IDE installed in parallel?

Glad to hear it's all working now!

I expect either one should work--if you don't have a reason to use the I/O device, though, I would go with the switch, particularly if it specifically mentions being able to autonegotiate baud rate (most often, it'd be listed as either 10/100 or 10/100/1000). I suspect that this is the reason for the issue (usually there's no issue, but every once in a while the networking phy chip on a slave device doesn't want to negotiate with the one on a PMAC), so a switch specifically designed to handle whatever speeds individual devices want is probably the safest bet. That said, if you actually do have use for the I/O, that would most likely work as well and would be two birds with one stone.

Stupid question, but EtherCAT was enabled when you attempted to read ECAT[0].IO[7].Data, correct? No information gets transferred automatically (ie, information would ONLY get transferred by ecatsdo commands, not by firmware) if EtherCAT isn't. I see you posted a screenshot showing them in OP, so I assume this was taken at the same time/everything was enabled, but still... Assuming that was the case, then most likely the mappings didn't really get loaded into PMAC, or possibly that conflicting mappings may also be loaded. To guarantee that no other mappings exist and that the correct ones are loaded, try this: //Factory Reset -- Issue these into the Terminal 1. $$$*** 2. SAVE 3. $$$ //Configure EtherCAT - Make sure you have a Project open before performing these steps 4. Configure EtherCAT through System Setup. Make sure all necessary mappings show up in either "Background Tasks" or "Foreground Tasks" (one of the two should have all of the inputs/outputs, one should be empty) 5. Right click on the master and export all of the EtherCAT variables. 6. Verify the existence of "ecatactivate0.cfg" in the Configuration folder (this should ideally have a few ecatsdo commands pre-populated into it) and that a file was created in Global Includes that lists all of the PDOs you have mapped. 7. Build and Download the project 8. Right click the "ecatactivate0.cfg" file and select Check to Download 9. Right click the Configuration folder and Download Selected Config files. 10. SAVE 11. $$$ 12. Enable EtherCAT (ECAT[0].Enable=1) If your ecatactivate0.cfg file is empty, you can leave it alone for the purposes of this test, but ideally it will have a series of ecatsdo commands setting parameters listed in the "Startup" tab to their correct values--typically 6060 is the main one required (to put drives into mode 8/cyclic synchronous position mode), though some slaves need other parameters, such as: 60C2, Subindex 1 and 2 - Interpolation Time Period 6072, Subindex 0 - Max Torque 607F, Subindex 0 - Max Profile Velocity Mind you, the vast majority of drives just need 6060, but these are some of the "next most common" parameters I've seen in case the drive is throwing errors related to communication or refuses to output torque/command motion (because it is Torque/Velocity limited to 0).

Well, that log does seem to tell us the error: EtherCAT WARNING 0-0: PDOs configured for SM2, but slave does not provide the sync manager information! EtherCAT WARNING 0-0: PDOs configured for SM3, but slave does not provide the sync manager information! EtherCAT ERROR 0-0: Failed to determine PDO sync manager for FMMU! Basically, you are properly configuring the PDOs for the Sync Manager (so PMAC is ready to transfer the data to/from the slave), but the slave does not seem to have the sync manager information programmed into its EEPROM. The EtherLab FAQ located at https://www.etherlab.org/en/ethercat/faq.php goes over it in a bit more info. Since that link does seem to be down right now for some reason, a cached version is available here. The "fix" at this point most likely involves reaching out to the slave manufacturer. You may be able to reprogram the EEPROM yourself using the XML file and TwinCAT, as the XML file should also have the same information, but vendors often do not realize that the slave needs it too as per the EtherCAT spec.

Unfortunately, that's not officially supported, and not something that Delta Tau engineers can really help with. That said, it may be possible, and other users may have done it or be able to comment.

Cyclic Synchronous Position mode is the correct one--while there are some users who have configured drives in Profile modes, the Cyclic Synchronous modes (Position/Velocity/Torque) are the only 3 officially supported. Can you try issuing "ecat reset", followed by "system dmesg" in the terminal? I know I'm somewhat emphasizing dmesg, but I'm just not sure why it doesn't seem to be displaying any error explanation. Since the response will likely be long, it may be easier to copy/paste the full response into the forums directly as text or to save the contents of the terminal window as a text file and attach it to your post.

Additionally, I believe you posted the dmesg from when the slave wasn't being detected. Can you also share the contents of dmesg when you get that error?

The issue with requiring a switch may be caused by an issue between the phy chip on the PMAC and on the Schnieder Electric drive. Do you ultimately intend on having more EtherCAT slaves, or will that be the only one? Putting a different device between them (such as a switch, but alternately another drive or an I/O module if you intend to use them) may fix it. As you noted, for EtherLab there are no log files aside from dmesg. -If the drive does not show any errors, if you ignore the error showing up in PMAC, are you able to do anything such as command motion or reading parameters from the drive? -Have you configured EtherCAT before in general on a PMAC? I just want to verify that you know the full procedure/have some sort of reference that you are following. -Can you confirm the value of ECAT[0].Error? That may provide more information.

I see that you specifically mentioned that the "error and error history" logs don't show anything. Can you check through the other logs? I unfortunately can't remember for EtherLab (the EtherCAT implementation on your CPU), but on Acontis, there is a file named "ecmaster0.0.log" and another named "error0.0.log"--typically, I would expect EtherCAT errors to go into one of those two files, rather than the "standard" pp_error.log or pp_error_hist.log.

Coord[x].ErrorStatus can signal many different things depending on what value it takes--you can read what each of them means from the "Power PMAC Software Reference Manual" in the File Depot. That said, though, we may be able to help more with troubleshooting the cause. One of our engineers thinks it may be caused by the fact that you are reversing directions [(10,0,10) -> (20,0,20) -> (30,0,30) -> (0,0,0)]. This may have caused a cutter compensation interference error, which is caused by a move in the opposite direction from the compensation. If this is the case, ErrorStatus would be equal to 10, and it would indicate that performing that move would likely result in an overcut. Another thought could be that it's caused by some "leftover" active G-Code that may not have been initialized properly. If this is the case, showing all of your active G- and M- codes could give us an idea, in case anything is listed as active that wasn't set from your G-Code. This was why we had asked for a larger screen shot, showing the full PPNC window.

Can you provide a full screenshot of the PMAC NC Software? Particularly the Positions and the sections below that, showing (amongst other things) the G- and M-Codes that may be active at the time where it stops. Do you have the Power PMAC IDE installed? If so, it may additionally be worth checking the value for Coord[x].ErrorStatus (most likely Coord[1].ErrorStatus if you are unsure), along with looking at the "Global", "Coordinate System", and even "Motor" tabs of the Status Window to see if any specific errors are showing up on one of the relevant pages for your system.

When using EtherCAT, Motor[x].AmpEnableBit is not used--the "pattern" that is sent to the Motor[x].pAmpEnable register is following a state machine that is part of the EtherCAT standard, and users do not typically need to alter it. That SRM entry is a bit written a bit awkwardly--the intent was to give multiple examples of proper registers to set Motor[x].pAmpEnable, and then afterwards to explain that Motor[x].AmpEnableBit specifies which particular bit of the intended register is used. When applicable, we tend to list local hardware settings, then MACRO settings, then EtherCAT settings, and in this case, that means that the EtherCAT example is immediately followed by "this is how you use AmpEnableBit" (despite it not applying for EtherCAT). The intent was for them to be separate statements.

Where are you getting this error message? I'm not used to seeing it from the Power PMAC NC Software. Are you able to post a screen shot of it? Does it seem as though it's a particular line of code? If you have the ability to do a "dry run" or run on a virtual machine, can you comment out sections of the code and see if it is being caused by a particular line? If you comment out sections of the G Code starting at the end and working forwards, can you narrow in on a specific section that is causing the problem?

Sang Joon, There's two different things at play. I believe querying a P Variable in Turbo would have resulted in a "no-op" (no operation to perform), and the line would have been skipped. In Power, it was decided to instead catch "no-op"s and send errors when they are encountered. As such, querying variables this way is not allowed in Power PMAC. However, you mentioned "calling M variables". This most likely is not simply reading an M Variable, but rather, executing M Code (from the same family as G Code). In this case, like the "M14" in your very first example program, you are not querying anything, but rather, issuing a command. As such, this is not a "no-op". Power PMAC does accept G, M, T, and D Codes, which will look similar to querying variables, but are handled differently. In Power PMAC, the command "P10" should always cause an error in a motion program. "M10", however, will likely tell PMAC to look for Line 10000 in the specified M-Code library.

Sang Joon, That doesn't really answer the question, though. I understand that the customer's code includes the line "P0360", but why does it include this? Even if this did not cause an error, at best, this line does nothing, and as such, we would recommend your customer remove this line. Querying a variable should not be a valid command for inside of a motion program or PLC--if anything, I would argue that it should not have been accepted in Turbo PMAC, not that it should be allowed in Power PMAC.

The easiest way to do this may be to add them to pp_custom_save.tpl. If you simply list the names of your variables there, build and download the project, and then issue a "save" or "fsave", they should be saved just like an I Variable would be. That said, are these parameters that you need to be able to save, or just parameters that you want initialized to a specific value? If you simply declare and set them in your project (such as by putting "GLOBAL MyVar = 5" in a file in your "Global Includes" folder), that would also allow them to initialize with your pre-set values.

Since it looks like Dave and Eric addressed the first question fairly well, i just wanted to chime in for your second question. HomeComplete and DesVelZero really do address two different things. For DesVelZero to go true, the motor must be trying to hold position OR be in open loop and not moving. For HomeComplete, the motor can actually still be moving, all it means is that a home command was issued and successfully found the trigger location. You may actually want to wait until both HomeComplete and DesVelZero (or HomeComplete and InPos would be even better, that way we know the motor is in closed loop and within the parameters of Motor[x].InPosBand/Motor[x].InPosTime) go true to be sure that the full home move is completed. The training materials we have in the file depot aren't our most up-to-date resources, but the Triggered Move section may help explain this a bit. I've attached one of the slides that shows a bit about when these flags go true.

That behavior still sounds odd to me such that I'm going to try to look into it in the coming weeks, though admittedly, it's a bit hard to do so as I didn't think to bring any ECAT slaves while working remotely. As for SDO reads during EtherCAT communication, that's close, Jeff. We typically don't recommend issuing too many SDO commands while EtherCAT is enabled specifically because, depending on the exact timing of it, it can cause interference and problems. I believe it is more related to if an SDO read forces the PDO read to take too long that it rolls over into the next PDO read period. This isn't too likely to happen if you just are reading one SDO every few EtherCAT cycles, but if you start reading too many of them or too frequently, this can break things a bit. Because of this, if someone is reading SDOs very often, we strongly recommend they investigate mapping them as PDOs altogether or possibly lowering their EtherCAT rate. However, this would be somewhat contradictory to the "fix" sutty found (where a slower EtherCAT rate causes intermittent issues), hence wanting to look into that more.

Is there a reason you are setting it up in IDE 3/EC Engineer, generating an eni file, and importing it into IDE 4? In IDE 4, you can do all of that (EC Engineer has been incorporated into the IDE). Please try making it entirely in IDE 4. To do this, either make a new project using the "PowerPMAC with EtherCAT (Acontis)" template or by right clicking the "EtherCAT" folder under System in the Solution Explorer and add an EtherCAT Master. After that, if you click on the Master, many of the screens should be the same as they were in EC Engineer, though if you go to the "PowerPMAC IDE Manual" under the Help menu, it can guide you through it. Once everything is finished and configured, I would issue "$$$***" to the PMAC via the terminal, then right click on the master and select "Load Mappings to Power PMAC", then perform a project Build and Download, issue "save", and an "$$$". After that, I would try to enable EtherCAT again and see what happens.

I apparently misread--because there were some mentions to the EL7211 here, I assumed this thread was referring to the same slave device as the other thread and did not notice at first that it is (primarily) about the EL7031. For DS402, the process of enabling the drive is a state machine that sets a register to specific values, then waits for the drive to signal via its status register that it is in the correct state. As such, we set the register specified by Motor[x].pAmpEnable equal to a specific value, then wait for the register specified by Motor[x].pAmpFault to go to a specific corresponding value. Seeing as your drive does not follow DS402 and will only accept one bit to enable, this won't work. Because the slave does not support DS402, our firmware doesn't really support it as a drive. It may be possible to use it anyways, but most likely, you will need to point pAmpEnable to a scratch register such as Sys.Idata[10], then manually copy that into 0x7010:01--this will trick our firmware into simply toggling a bit true/false, rather than going through the state machine required to enable an EtherCAT slave. Putting all this together, this most likely means your settings will look something like: Motor[1].pDac = Motor[1].pAmpEnable = Sys.Idata[10].a Motor[1].AmpEnabl0eBit = 0 //Assuming you want to toggle Bit 0 of the EtherCAT register to enable Motor[1].pAmpFault = Motor[1].AmpFaultBit = 0 //Assuming Bit0 of the EtherCAT register will toggle when you encounter a fault Motor[1].pEnc = EncTable[1].a EncTable[1].pEnc = OPEN PLC AmpEnableCopyPLC = Sys.Idata[10] CLOSE ENABLE PLC AmpEnableCopyPLC That PLC would need to stay running at all times so that you can properly enable/disable the slave. There are other ways to do it, too (a user servo routine would be synchronous to the EtherCAT clock, for instance), but that would be a simpler way. Again, I can't promise that this *will* work--officially, this drive does not use a protocol that we support. However, this would probably be what I would try myself.

To clear up a few misconceptions: -EtherCAT is based off of the Servo Clock, not the Phase Clock -As EtherCAT is based off of increments of 62.5uS, it is not expected to work at faster than 16kHz (and even that speed exceeds the limitations of most devices)--I am not sure if this is a limitation of our implementation or if this is a normal EtherCAT spec, but I haven't seen EtherCAT conforming devices rated for faster than 16kHz, and more commonly 8kHz is the fastest I've seen for drives -I am not sure what speed you are using EtherCAT, but I suspect that you are not properly setting ECAT.ServoExtension to accomodate having different values for your servo clock and your EtherCAT clock. Can you please query: l0=ecattypedsdo(0,1,1,$492,0,0,4) l0 $492 may not be 32-bit (size = 4), so if that gives nan, please query other sizes. In general, any device that is properly identifying itself as a drive will show up as an option in the system setup. If it's not there, it's either because we can't read the settings from the drive by using ecattypedsdo or that the devices are not properly identifying themselves in registers $1000 (which you queried) and $492.