Eric Hotchkiss

The items in the hardware folder are hardware diagnosis tools. It's a bug that they are still not added into IDE 4. However, this will not stop you from setting up your PMAC. You can add a motor to the Motors file or add code from manuals to the Global Includes folder farther below.

If you connect a Micro-USB cable from your computer to the port on the front on the CK3M and find the COM number, PMAC can be accessed the same as it was through RS 232. The port on the back is for accessing the CK3M's storage.

If you set Sys.ServoPeriod=0.125, does it immediately go back to the other value? It might be that the issue is the system setup config being downloaded and replacing the value on reset.

If you look at the value of Sys.ServoPeriod, is it 0.5 or is it a float value slightly off from 0.5?

I think Richard's response assumes the encoder tapes are carefully placed end to end, not overlapping. Is this possible?

You can manually add the motor back in. Just click the gear in the top right of the position window and type the desired motors into the box.

This is a known issue with IDE 4.4.0.99. I have seen (remotely) that the issue is fixed in the current builds so it will be fixed in the next IDE release. For now, if it bugs you too much, I would revert back to IDE 4.3.2.19. https://automation.omron.com/en/us/products/family/PMAC%20IDE

It sounds like there is a trick to make this work. Hopefully this post will get an update soon.

Commanding the motion program to run through C doesn't help me replicate the problem. Can you make a C program that just has the Motion program already in quotes and builds then runs it to see if it can replicate the issue?

It should be fine to go directly to your desired firmware version by USB.

From my testing it looks like Motor Position (like in the watch window) does not jump from these settings, but Motor[x].PhasePos does, which causes the motor to be uncontrollable. Please confirm the first statement by changing Motor[x].pEnc/Motor[x].pEnc2 with the motor killed so the changes do not move the motor. The position should not change. Phase position is a little more difficult. I would recommend killing the motor before setting Motor[x].pPhaseEnc and rephasing afterwards. As long as the motor does not move during the process, it should technically be possible to set Motor[x].PhasePosSf=0 during the change and then immediately back to the original value after to prevent the jump. If the motor moves while PhasePos=0 it will need to be rephased before it can be put back into closed loop. This all assumes both encoders are identical. If they're not, you may have to change some scale factors.

You can run tsel from a motion program by putting it into a subprogram and running that from the PLC with: CMD"&1 CPX CALL {SUBPROGRAM NAME}" If a motion program is running already, that may be an issue.

Do you have a good current loop response? Can you manually phase the motor and pass an open loop test?

Can you check with Yaskawa that those mappings are fully configurable? I don't think the Copley ones in that range are.

Jeff, are you using Acontis or Etherlabs EtherCAT on your quad core? I feel like you could be making some assumptions about how Acontis works based on Etherlabs. If Acontis, you may want to take a look at the hot connect groups described starting on page 182 of the current IDE manual. They basically allow you to set up two versions of your ECAT network and switch between them.

What type of encoder is this? Are you saying Motor[x].EncLoss goes true as soon as you issue settings for Motor[x].pEnc and Motor[x].pEnc2? If so I will need more information because I am not able to replicate the issue? Are you saying Motor[x].EncLoss goes true when you unplug the first encoder after switching? If so take a look at the setting for Motor[x].pEncLoss and change it with pEnc and pEnc2. I am not able to view your attachment.

For a +/- 10 volt analog amplifier, there is a voltage signal provided from PMAC that is proportional to commanded current. Transcanductance is the ratio of current commanded into the motor to the size of that signal voltage.

There is a known issue where if you change a gain and don't click out of the box before running the tuning move, the window has a small chance of crashing. Do you think this could be your issue? I know some changes to the tune tool are coming that will address this issue.

Gate1.Chan[j].Pfm values of 1900 and 2000 should correspond to Pulse Output frequencies of about 1.11 and 1.17 kHz. That should be higher than the servo frequency, so you may want to slow down your servo by changing Acc24E2A[4].PwmPeriod, Acc24E2A[4].PhaseClockDiv, Acc24E2A[4].ServoClockDiv, and Sys.ServoPeriod. The easiest way would probably be setting Acc24E2A[4].ServoClockDiv to 9 or higher and then recalculating Sys.ServoPeriod to match. Alternatively, since your MLDT is only about 32 inches, you can probably use a pulse output frequency high enough you don't need to change your servo frequency. The Users manual says you need 0.35 micro seconds per mm. This would only be 284.48 microseconds, allowing a maximum frequency of 3.5 kHz.

Can you replicate the issue without the HMI if you make the C App dumb the program into the buffer?

Like the latter, but it is allowed to be greater than 1. Use 1 to move with Motor[x].JogSpeed

Are you intending to use the encoder or not? If not it would be best to start with the "Stepper Motors – Direct Microstepping without Encoder" example, but will the following changes: BrickLV.Chan[].TwoPhaseMode=0 Motor[].PhaseOffset = 683 Motor[].PhaseMode = 0 I2T Protection would already be correct for a 3 phase motor in that section, but once it's updated to be correct for 2 phase you'll want to keep the cos(30) like below: Motor[].MaxDac/I2tSet = PeakCurrentrms * 32768 * √2 * cos(30°) / MaxAdc

By default PMAC looks ahead a limited number of segments. With Coord[1].SegMoveTime at a non-zero value lookahead is disabled. If you want lookahead with SegMoveTime you have to define a gather buffer and then set Coord[1].LHsize above 0. Can you replicate the issue without the C App?

The documentation for JogSpeed(n,x) is not great. It will jog motor n indefinitely with Velocity = x * Motor[n].JogSpeed. Set x negative to reverse direction. Motor[n].MaxSpeed should not matter.

I am not able to replicate the issue. I thought I had it at one point, but that was just because BB wasn't in my frax and was moving VERY slowly. Do you know if you are using lookahead? What are Coord[1].LHSize and Coord[1].SegMoveTime?