Motor setup dynamically

[Ian Nicholson]

We support machines that have varying hardware, but otherwise operate mostly the same. In particular I'm thinking about servo motors/amplifiers (and even gear-drives with differing gear ratios). We've been supporting some of these machines for over 20 years, and others are only a couple years old or even newer. As products are phased out, we are forced to change to newer parts with different characteristics, and the software must adapt to this. We are now at the point where Turbo PMAC Clipper is not really available anymore, so we are working on moving over to CK3M.

As some of the older machines have components fail, we must upgrade them with parts that are currently available. Also, as time passes we add capabilities to our machines; for instance our modern machine has an additional axis that the older machines do not have. The software needs to support 

What is the best way to dynamically assign/configure these motors depending on the machine type and component specs? When I add motors to the Project -> System -> Motors list, they are tied to specific hardware. If I want to use this project to control multiple machine types, I need those motors to be configured in PPMAC on the fly (my current plan is using fsaved variables to specify the current hardware configuration, and have the software assign motors based on those parameters). Can I delete the motors themselves and just set them up in code instead? For example my initialization PLC?

With Turbo PMAC, we used the .CFG backup files to develop with and we kept separate a .CFG file for each machine type. Through the years we now have at least 30 different .CFG files for the different combinations of hardware, and if any fixes are made in these files, those fixes must be grafted into any other machine type .CFGs (we obviously only do this as needed since the workload would be massive to update all at once). I don't want to end up in this situation with PPMAC (esp. since PPMAC doesn't really have a single-file option) so I'm trying to develop a more universal approach so any machine type we retrofit with PPMAC can be run with the same software by setting a few config options.

Edited August 8, 2022 by Ian Nicholson
sp.

[David White]

You can still set up everything using a configuration file in ppmac. You don’t actually have to create the motors in the project, although it’s much more visual if you do.

 Once a machine is configured you can Generate a configuration file (right click on configuration)

You can have many differing configuration files in the project. They can be imported into a blank project and used to set up a new pmac even if no motors or coordinate systems have been set up in the IDE

 Right clicking on the configuration files allows you to select “check to download” then right click on the configuration heading and select “download selected” into a new controller

 The settings still go down to the new CK3M just the same. They just won’t appear in the IDE. You have to do this each time a project is downloaded if you have any motors or coordinate systems defined in the ide as these will override what’s been downloaded from the cfg file

 If you do have motors set up in the ide, it is possible to right click on the motors heading and upload motors settings from the pmac. This doesn’t create motors in the ide, just uploads the settings so the project matches what’s been previously downloaded. Doesn’t always work if they are very different types of motor hardware though as the ide tends to want to hang on to basic settings that are created within it. 

 You can also upload the coordinate system settings and encoder table into the ide in the same way. They have to be created in the ide to match what is in the pmac but will then upload settings for  that coordinate system from the pmac.

 Things not defined in the ide won’t affect things in the pmac when a project is downloaded.

 So whatever is sent by the cfg file stays unless overwritten buy something defined in the ide.

Older ide’s had trouble with uploading correctly from the pmac, particularly the encoder conversion table. The newest one seems better

Hopefully I’ve communicated all that clearly.