Alex Anikstein

I'm not sure if you have the Power Brick AC or Power Brick AC ARM, but for either one, the "Manual Force Phasing" on Page 182 of the Power Brick AC ARM Manual should do that. In short, the by writing an acceptable value to the B Phase Bias parameter (with nothing on the A Phase), the motor should lock into its zero angle for commutation.

I do still believe that a different method may be better, but for now, if you use an L Variable directly, you should be able to loop across Motor[x].CoordSf. Internally, LOCAL declarations associate the names you create with a pre-existing "L Variable"--that's why in the error message, it says L322 instead of "ratio", L320 instead of "mot", and L321 instead of "ax". If you replace "ax" specifically with "L150", it should work. You can use other L Variable numbers if you prefer. The key seems to be it must be less than 223. It is not ideal, but similarly, you likely could even write "#define ax L150" instead of "local ax", and then you could use "ax" exactly as you intend successfully. If you do this, I would not include the semicolon on the end of the line; #define is a direct string replacement, so if you say "#define ax L150;" that may replace every instance of "ax" with "L150;", thereby breaking many other lines.

Roman, We're still looking into this, but to consolidate, whenever we figure it out I will reply in the other thread.

Just so that it doesn't look like we're ignoring this, I'm still trying to figure it out. It looks like the problem is specifically having a variable index for CoordSf, though it was allowed in the terminal. I'm consulting with our firmware team to try to understand why it's blocked. ...that said, though, if you are using kinematics, I wouldn't generally recommend using Motor[x].CoordSf. It's really intended as a read-only parameter being set by standard/linear axis definitions, which aren't recommended to be used with kinematics anyways. I was initially going to suggest you define all axes with correlations to all motors, then use an axis transformation to "clear" the motor and axis interactions that are not being used (plus appropriately scale the axes being used), but this wouldn't really work for kinematics. Are there set "configurations"--customers will either have , , , etc.? If so, then the easiest way to do this may just be to implement all of them and use a SWITCH statement in the kinematics--now the user would just toggle potentially a single variable via ssh, and then when they go to run their motion program, it will utilize whatever configuration is indicated by the correct case. This could even be done piecewise, so the "base" kinematics are always used, and then use a SWITCH based on options the end user might have to implement kinematics for those, too.

The linked document (Power PMAC Software Reference Manual) should now be available on the appropriate Omron website instead of in our File Depot. For instance, for users in the Americas, they would download it from manuals section of their related product page on the Omron Site (I chose the CK3E page, but it is also on the CK3M and UMAC pages) or by searching for "Power PMAC Software Reference Manual".

A few different things: 1) From the "kinematics" you listed, you don't actually need kinematics. You could just do: &1 #1->X #2->Y #3->2000Z #4->2000Z - 2000 2) I am not certain, but the "p" command might have only been returning the position for Z because you had set "KinAxisUsed = KinEnaAxisZ". Had you set "KinAxisUsed = $1C0", it might have returned X, Y, and Z. 3) Similar to #2...you technically can use both axis definition statements and kinematics, but you will still need to include all axes in the forward kinematic buffer. Because you still need to put it there, we strongly recommend either using all axes in the kinematic buffers or none just to keep it straight forward. 4) To your actual question, where are you running that code? In the terminal window, for instance, I could set or query Motor[x].CoordSf with local variables for both x and i, which makes me think there is something else going on. From the syntax, I am assuming that is some sort of C code, though I am not sure where exactly you are running it.

I'd like to actually ask a different question--why does your system need to support changing coordinate system configuration via SSH? If it's a matter of stretching/rotating and adjusting the scale factor for an axis, transformation matrices are the recommended way of implementing that. Typically, we do not really recommend varying coordinate system definitions "on the fly".

Unfortunately, for a given coordinate system, either all axes need to use kinematics or none of them can; they can't be mixed. That said, the "solution" is to point their Axis Definitions to I, then add KinPosAxisX = KinPosMotor1 KinPosAxisY = KinPosMotor2 to your forward kinematics and then KinPosMotor1 = KinPosAxisX KinPosMotor2 = KinPosAxisY to your inverse (and similarly set KinVelMotorn and KinAxisUsed to reflect all motors). Because the basis of a coordinate system--and kinematics itself--is that the motors are all "intermingled" and working together, PMAC wants to just look in one spot for all relevant motors.

You mention that you can connect both drives "without any issues" when you change and configure that alias numbers in the system setup window. To make sure I understand your issue correctly--you are getting the desired results through the IDE, but you just want the option to do it manually, correct? 1. Can you confirm which version of the IDE you are using? 2. (Depending on IDE version) At the bottom of system setup, it will list every command that it issues. What happens if you issue EVERY command the System Setup does, one at a time, in the terminal window? It might be that you can only issue that when PMAC or the slaves are in a specific state, so System Setup might issue more commands before/after the "ecat alias X Y". Alternately, there might just be a typo or mistake in the command you are issuing.

Different CK3M products have licenses for different numbers of axes--one of them does supply for 8 axes, but a different one is licensed for 4. Since this seems like it's something specific to your hardware, it would likely be better resolved over email. Would you be able to send an email to ODT-Support@Omron.com, including: -A link to this thread -A screenshot to the response to "ecat reset" (I believe there may have been typos in the path you posted, so a screen shot will help guarantee accuracy) -The serial number of the unit (likely 8 digits, beginning "C000", on a black-and-white barcode sticker) -The model number of the CPU (it should be written on the module, likely "CK3M-CPUxxx") We will likely ask you to issue a few commands to get more information and then figure out how to proceed from there.

I don't know anyone with experience with Sankyo Seiki robots/motors. It is possible that we can communicate with the encoder, but from looking online, I can't quickly find what serial protocol they use. There are certain protocols that would need a (factory programmed) Accessory 84B to read, and others that we simply can't read, but the Gate3 inside the Power Brick can be configured to read a handful of protocols via software. The Power Brick AC manual does list how to interface with a number of serial encoders--if you know the number of bits of resolution, your best bet might just be looking at the pinout to see which signals are used, wiring them to the Brick, and then trying out various serial encoder protocols/configurations, only changing the number of bits. If you get the right protocol, turning the motor you should be able to see the data changing. However, without knowing exactly what protocol they use, the recommended clock speed, encoder resolution, etc., it's not something I'd be able to directly tell you how to do.

What happened that led to this? Was the unit possibly re-imaged after receiving it? Or has it been like this since it was first received ("out-of-the-box")?

Geoff, I'm not certain about that warning, but I think you might be issuing the wrong code. Typically, pMasterEnc is set as: Motor[6].pMasterEnc = EncTable[12].a (not pEnc) So can you try instead to issue: pshm->Motor[6].pMasterEnc = &(pshm->EncTable[12]);

If you are trying to just read PMAC commands, you can issue the Linux command "gpascii -i/" So if you have a text file named "Commands.txt" loaded into the "Documentation" folder of your project (already downloaded onto PMAC), you could issue in the terminal: system gpascii -i/var/ftp/usrflash/Project/Documentation/Commands.txt Note that issuing this from a PLC or Motion Program would use the "system" command and require quotation marks, though the above syntax should work in the terminal. Depending on what the parameters are, you could also look into using "pp_custom_save.tpl" along with the "fsave" and "fload" commands--so if you wanted to back up Motor[1].JogSpeed, you would: 1. Put "Motor[1].JogSpeed" into "pp_custom_save.tpl", then download the project 2. Set Motor[1].JogSpeed to the desired value 3. Issue "fsave" 4. Do other tasks, including possibly changing the jog speed or power cycling the PMAC 5. Issue "fload" to re-load the saved values Now, if you need to parse the text file (ie, if it isn't formatted properly to be directly issued to PMAC), then you would likely need a custom C Application that could parse it and issue the correct commands, but that would be a different task.

Can you post a simple program that you're writing that isn't working? It's possible you're missing some other command. For instance, if you do not specify the centerpoint correctly, it may effectively treat it as a straight line. Depending on if this would be safe to do with your motors, try to move to the absolute location X = 10, Y = 5, then issue: Normal K-1 Abs(X,Y) Inc(R) Circle1 F 10 X 25 Y 30 I 20 J 5 That should yield a quarter circle that looks like this.

If Motor 2 works, but Motor 11 (with otherwise identical settings) doesn't, what value is Sys.MaxMotors? Is it possible that you have multiple motors writing to the same target register at the same time? If Motors 2 and 11 are both set such that Motor[x].pDac = PowerBrick[0].Chan[0].Pwm[0].a at the same time, the motors will fight one another and overwrite each other. Just to make sure you don't have any other motors that might be conflicting, can you try to set Motor[x].ServoCtrl = 0 for all motors other than Motor 11?

You can find most useful manuals from the File Depot, available from a link in the top right of the forums (if you're logged in). You can download the Geo Brick LV Manual from there which should guide you through your setup as Greg mentioned. I would also making sure you have the Turbo PMAC Software Reference Manual (SRM). You can think of it as a "dictionary" of sorts so you can look up what a specific command means and how it works, but I wouldn't sit down and read it from cover to cover.

To add on quickly, there actually are two licenses--one software (which has the potential to be corrupted or lost during device imaging) and also a hardware license. As such, adding EtherCAT does still require sending the unit to the factory, as the hardware license must be programmed in person using special hardware and software.

Can you give us more information? I just downloaded both the .iso and the .zip from the file depot. On Windows 10, I was able to run both .exe files. I did not need compatibility mode, though I did run as administrator. Are you getting an error message? When you run .exe, does anything seem to happen at all? Did you download .iso or .zip? Did you extract the files before running? There is a chance the download may have failed, too. If the software doesn't open at all, please try to re-download, too. I don't have a system, so if the software *did* open, but then does not work, that is different. This is as far as I got.

It just felt like it had to be firewall, because it really does seem like the "transfer data from PMAC to computer" step is specifically what's being blocked. Are you able to do a motor tuning move (a Step move, for instance) in the Tune tool, and do you get a plot when you do? It's sounding like this may be something fairly specific to this computer/installation. Would you mind sending an email to odt-support@omron.com (and include a link to the forum post in the body)? I think at this point it may be easier to troubleshoot this over email.

What IDE version are you using, what firmware version is this particular PMAC using, what PMAC type is it (CPU + form factor), and does the plot feature work for any other computers? It may be that your firewall is blocking "DeltaTauGatherProgram"--be sure to give that process the full permissions in your windows firewall. It sounds like the problem is specifically when trying to pull all the data off of the PMAC ("normal" mode streams the data continuously, "legacy" leaves it in the PMAC and only transfers it when you click Upload), so this is the most likely culprit. If this doesn't solve it, then please provide the info above in case any of it is relevant, since it might be a firmware/software mismatch or something.

Jeff, Can you give it a bit and try again? We've seen that before and are trying to figure out a cause, but in the meantime, it seems a bit inconsistent and goes away on its own after a bit.

Power PMAC IDE v4.4.1.7 has been released and is now available on the Omron Website through the "Power PMAC IDE Download" link.

It looks like it just went down for a few hours for some reason--it was down last night (I tested it, too), but it appears to be working again now.

That's unfortunately a software bug. It's been reported, but the fix is not yet included in the released version. Under close inspection, the variable names actually do not match--see the added underscores in the "Watch EtherCAT Mapped Variables" window. The fix at this point would be to make them consistent, most easily by changing the ECATMap.pmh to add the underscores (or add additional #defines so that both names can be used).