Alex Anikstein

Please make sure the devices are all properly connected--it may be useful to disconnect and reconnect them all. What is the response to Sys.Gate3AutoDetect? On each of the modules (AX module, MD modules) there should be a rotary switch for addressing. Make sure these are all at unique addresses (likely 0, 1, and 2). If you just have a single module (Power Supply + CPU + either AX1515 -OR- MD7110 -OR- MD7120), does the device show up? If the address switches are set at unique values, then please try each module one at a time to verify they work on their own, and if they do, then try two modules at a time and see if they work.

In general, all of our software is distributed for customers in the Americas through the Omron website now. If you search for "PowerPMAC IDE 3", you will see a number of versions available for download, including 3.1.4.0, our final release of version 3.

Unfortunately, the product news may have "jumped the gun" a little bit. IDE 4.6.0.x is expected to be the next release, but at this point it is not yet publicly available.

If you monitor Acc24E3[1].Chan[0].Status in the watch window, do you see the correct bits changing when you physically engage your flags? Do you have Motor[x].CaptFlagBit set correctly for the signal(s) you want to use? I think there may be a more fundamental issue, though. Do you actually have an alternate position sensor configured to Acc24E3[1].Chan[0], or is it just the flags? If you set pCaptPos to look at Acc24E3[1].Chan[0].HomeCapt.a, then ultimately that will be the position you use as your home value. If you don't have a secondary encoder that Acc24E3[1].Chan[0] can read, this will likely not work how you want. Especially if the encoder and signals are coming into different Gate devices (ie, encoder in Acc24E3[0] and flags in Acc24E3[1]), now the capture cannot be handled entirely in the hardware of the Gate3 ASIC since no one ASIC has all of the information.

What version of firmware is on your system? You can find out by using the "vers" command.

As of now, it is still being worked on. We have a method we are exploring fairly strongly, but because it changes some parts of communication, we want to carefully consider the options and implications before we implement it. Honestly, that's not a bad idea. I'm not sure if it's feasible or what it would take to implement, but I will pass it along anyways. I still don't really have a timetable to present for when this will be resolved, but we do hear it clearly and it is receiving an appropriate focus from our developers.

Can you share with us the firmware version you're using? Additionally--you say they "can't stay online". What exactly happens?

Users that want functionality like this will often make a motion program that uses a series of small moves which blend together--something like: OPEN PROG MotorJog WHILE(JogFlag == 1) { LINEAR INC F10 F0.1 } CLOSE They would then need to run the motion program in the Coordinate System, then set the flag.

robodavo is correct, it is effectively a rounding error. I believe this is set to be fixed in a future firmware release, but for now, you may also be able to fix it by setting Coord[x].MinArcLen to a trivial, but nonzero value (think 0.00001).

I don't think I've seen that one specifically before (IDE Crashing specifically after testing is successful). We may be able to submit a bug report for our software team to investigate, but we would need much more information (which IDE version, which PMAC product, which firmware version, what type of motor, which screens specifically are you on when it crashes...ideally, a screen recording would be even better than a description of where/how it crashes). While we are still actively working on developing the wizard, we do acknowledge it does not cover all of the things users can do with Power PMAC. Without knowing your PMAC, it's hard to direct you to a specific document, however the Power Brick LV ARM manual does have a section discussing how to configure a Sinusoidal Encoder being read through a product with the ACI option--the settings should be nearly identical for most hardware form factors.

There isn't really any pre-made structure to tell you where you are, no, usually if customers need it, they'll either use a workaround (like you said) or increase their resolution of their path (commanding many smaller moves so they can track it with Nsync). That said, take a look at the "Axis Target Position and Distance-to-Go Reporting" section of the Power PMAC User's Manual--it may be able to help. It's not directly a percentage, but it may help you at least determine where you are presently inside of a move.

Typically, motion programs would use the "pread" command, which would load all axis positions into pre-set variables, from which the motion program could then read them. The "#1p" command does not return the position "to the terminal", it returns it to wherever the command is issued. If you issue it in the terminal, the response goes there, and if you issue it to a motion program, the response would get issued to the motion program--however, it doesn't have any way of receiving or displaying it, so it effectively gets lost.

I am not aware of a "built in" way to read this. PMAC might store the line number as an L Variable inside the calling function, which in turn means it would be accessible as the same-index R Variable inside the called function. However, if that is not the case, it may not be possible without modifying the calling function, which likely isn't a viable solution.

Somewhat. You can use Linux commands from Motion Programs or PLCs by using the "system" command, potentially in conjunction with "Ldata.SystemCmdStatus" and/or "sendallsystemcmds". If this is in relation to your other thread, though, you are better off just using the "send" command. Sending Linux commands from Motion Programs/PLCs may not work exactly as you want, depending on the command. If the command is not "instantaneous" (such as if it requires waiting for some response/other action to "finish"), it may run into issues. For echo, I would not expect this to cause many problems, though.

Printing to the terminal window in the IDE from another source isn't especially easy. A better option would be to use the "Unsolicited Messages" window, which was designed to do exactly that. It is available under the "Delta Tau" dropdown menu, and by default it will listen on "Buffer 0". You can then use the "send" command in the motion program to broadcast a message out on Buffer 0 for the Unsolicited Messages window to receive. You can find more information about the Unsolicited Messages window in the IDE manual, included with the IDE under the Help dropdown. You can find more information about the "send" command in the Power PMAC Software Reference Manual, in the "Power PMAC Program Command Specification" section, including a few examples.

We have a larger application note titled "Advanced Data Gathering on Power PMAC" which may give you some good guidance on using the Gather program to do this. You should be able to request it from your appropriate Omron support representatives for them to get for you. That said, as somewhat of an excerpt, we have used code that looks roughly like this: int main(void) { InitLibrary(); char str[100]; while(1 == 1) { while(GatherFlag == 0) sleep(0.001); GatherFlag = 2; sprintf(str, "/usr/bin/gather > /media/disk/MyData.txt"); system(str); sleep(0.001); GatherFlag = 0; } CloseLibrary(); } In that case, when an external program sets "GatherFlag" to 1, this will stream the data actively being gathered into a text file on a flashdrive inserted into the PMAC. Once the data gathering is stopped, the flashdrive can then be removed and the data can be observed on another computer.

"pp_custom_save.tpl" and using fsave is the "officially" supported method by the firmware. There are other methods that can be implemented by the user, though. If you contact your appropriate Omron support team, they should be able to provide you copies of two application notes ("Using a USB Flash Drive with Power PMAC" and "Using Power PMAC’s User Folder to Save Data") which detail methods.

When you fail to get a response to the ecatregreadwrite, do you get a response to the "pmac slaves" command? I am wondering if that particular command is unresponsive, or if disabling EtherCAT also "broke" something about it entirely.

Our developers are aware of this issue and looking for possible solutions. We've passed your results on to them in case it offers any additional insight. We have a few different ideas for how to internally solve it, though I am not sure what the time table is as none of the "fixes" are particularly quick. It's not an ideal workaround, but for now, we would generally recommend not opening/closing the IDE or many tools while the PMAC is actually running, but rather, trying to open any windows beforehand.

Just as a note, /opt/ is write-protected by default. You may also need to issue one of: mount -o remount,rw /opt mount -o remount,rw /opt/vfat **May be necessary on Quad Core systems If you do, you would also want to re-set it as write protected after: mount -o remount,ro /opt mount -o remount,ro /opt/vfat **May be necessary on Quad Core systems

This ended up moving to email and likely has been resolved. It seems like it's some settings in Linux--specifically "ClientAliveCountMax" and "ClientAliveInterval" in the file located in "/.readonly/etc/ssh/sshd_config". Increasing these variables should increase the timeout before the ssh session is closed. (Alternately, setting ClientAliveInterval to 0 should disable this timeout altogether)

There is no real "maximum size" for Motion Program buffer. Motion Programs can be as big as you have space in PMAC. If your program is bigger than default (16MB), you are correct, raise maximum size. By default, much of PMAC memory is "empty". This allows users to change buffer size limits if they want to use more. Alternately, if their project gets very big or they have many C programs, they can use memory for that. PMAC does also have "binary rotary buffer" function. Look for "rotary" in Software Reference Manual or PMAC User's Manual.

For reference, that is the current answer. We are still looking for a better solution. We hope to be able to post firmware on the site for Omron in the Americas shortly (preferably under the individual product pages), though this is still in progress. We likely will not post all firmware versions there, however the intent would be to have at least the last few releases. For a bit of the "behind the curtain" stuff (and to also answer your question about 2.6.0.0), the attached picture is one of the current proposals. Black Box = Doesn't exist and/or not released White Box = Previously released Yellow Box = Released, proposed to post online (Note that the "merged" boxes mean that a single firmware file works on multiple form factors) The hope would also be that, if we can resume posting firmware publicly, other regions would follow suit and supply it to their customers in a similar manner.

Unfortunately, we are moving from one facility to another right now and do not have access to multiple EtherCAT devices to test. It should be possible, but it will likely be a few weeks before we can provide specific guidance.

Unfortunately, it's more similar to Modbus, but not quite the same. To use E/IP, it does have to be licensed. At this point*, this license is provided automatically with no charge on new units purchased. For units previously purchased, it can similarly be added through an RMA, though this likely has a cost associated with it--I am not certain. You would just request an RMA to add E/IP to the unit and they should be able to appropriately quote it. It will need to be shipped back to a factory; at this point the procedure cannot be easily done remotely. *I am not aware of any plans to charge for licenses on new units in the future, however I also cannot guarantee anything. Plans may change, etc.