Machine setup data

[DaveBarnett]

I am curious about dealing with machine setup data that needs to be static for a given machine, but still allows technicians to change very infrequently from machine to machine, site to site.  I know about how "fsave" variables effectively give Non-Volatile memory locations ...but, I don't really trust it ...or like the idea of casual users having programmatic access to the machine.

'Curious if any experienced users on this forum have come up their own way of dealing with this and what the strengths and weaknesses of alternative methods might be.

Thanks in advance...

[MoMo]

My personal experience is that I don't trust the settings generated by the IDE software.

Usually I write the settings into the Global Includes folder, and disallow PPMAC from using systemsetup.cfg.

It is very reliable to use the "fsave" command to temporarily save the contents of certain variables. Our users have been using it without any problems.

[DaveBarnett]

Thanks for the reply.... For sure the settings created by the IDE need to be heavily scrutinized! … But that's not what I’m talking about.  Imagine you have dozens of machines out in the field, but the only difference between them is, let’s say… a gearbox ratio, and this could change over time. It would be cleaner to put that gearbox ratio in an f-saved variable than to have an entirely different project just to deal with one variable change.  But, it means someone in the field needs to be trained in the use of the IDE, exposes other problems, etc.  I suppose a custom application could be written to handle manipulating only this single variable…but that carries some baggage, too.  

For one project, I added a rotary BCD switch wired to some unused I/O that allowed maintenance to choose among 16 options for the machine without using a computer.  It worked out well.  I’m looking for something akin to that, but that would work for a floating point number with high precision.  

 

Edited February 23 by DaveBarnett

[Omron Forums Support]

You might look into something like the OMRON NB3Q-TW01B-V1 touch screen HMI for OEM with 3.5-inch TFT color LCD display,  ModBUS TCP.  Looking at products on the website, I think that's the lowest cost solution of that variety.  

Contact ODT tech support for details.

[MoMo]

I think your idea is very creative.

I don't know much about your equipment, something like this can be fixed in the controller as a file. Or modify and set through a host computer software.

I may not want unrelated personnel to easily change the PMAC controller configuration through DIP switches. I personally prefer to perform this operation through a dedicated host computer software.

I think your needs can be met, but it will be a little more complicated.

 

[MoMo]

On 2/23/2024 at 9:12 PM, DaveBarnett said:

Thanks for the reply.... For sure the settings created by the IDE need to be heavily scrutinized! … But that's not what I’m talking about.  Imagine you have dozens of machines out in the field, but the only difference between them is, let’s say… a gearbox ratio, and this could change over time. It would be cleaner to put that gearbox ratio in an f-saved variable than to have an entirely different project just to deal with one variable change.  But, it means someone in the field needs to be trained in the use of the IDE, exposes other problems, etc.  I suppose a custom application could be written to handle manipulating only this single variable…but that carries some baggage, too.  

For one project, I added a rotary BCD switch wired to some unused I/O that allowed maintenance to choose among 16 options for the machine without using a computer.  It worked out well.  I’m looking for something akin to that, but that would work for a floating point number with high precision.  

 

 

You can use the script's preprocessing instructions to implement different settings.

 

The example is as follows:

 

 

Then you can directly modify the predefinition in us'rflash via the sed command in Linux, such as the “_Machine_1” in the example above.

Use the instructions below to switch the _Machine_1 to _Machine_2.After that, all you have to do is send $$$ and you'll be able to use the new settings

system mount -o remount,rw /opt
system sed -i 's/#define _Machine_1/#define _Machine_2/g' /opt/ppmac/usrflash/Project/PMAC\ Script\ Language/Global\ Includes/global\ definitions.pmh
system mount -o remount,ro /opt

 

 

 

 

 

Edited February 26 by MoMo

[Ian Nicholson]

Currently I'm using FSAVE variables in exactly the manner you described, to adapt the project for a specific machine type. I defined motors in the IDE the preferred way, then recorded their values and delete the motors from the project. Then I placed all the values I recorded in axis-specific subprogs that get called from my startup PLC and use the various FSAVE variables with SWITCH statements to determine which motor parameters to use to bring each motor online with the proper settings/scale-factors, etc. As time goes on and we adapt this project to fit some of our legacy machines, I add cases to the SWITCH statements to accomodate different motor/gearbox setups. When commissioning a machine or retrofitting it, we have a text file containing all our FSAVE variables for each setup, and we copy the contents of one of these files and paste them into the Terminal (I'd love to see a better method for this), then issue FSAVE and $$$ to load the proper setup values. At first I was unaware of the option to avoid downloading systemsetup.cfg, so maybe I can retool this a little, but I was unsure how to use conditional statements within the global definitions to set these, so what I have done works fine.

One thing that bugs me about FSAVE variables in PPMAC is that contrary to the way Turbo PMAC did things, on PPMAC when you issue a full reset command ($$$***), it wipes out the FSAVE variables as well. Normally this is fine since they are restored as you download your project, but several times I have inadvertently deleted all the FSAVE parameters we were using for machine adaptation when trying to clean-slate the PPMAC (for instance, when someone forgot to set the address switch properly on one of the axis-interface modules on a CK3M, and I had to clear the project and reload it to get going). If you issue $$$*** and then SAVE, FSAVE variables are gone, at least in my experiences. I know clean-slate implies deleting *everything* but Turbo PMAC left them untouched and I've come to rely on that fact. I'm not sure if this is intended behavior or an oversight, but it is frustrating. Maybe this can be addressed in the future? Or worst-case I think I read I can write some C-code to implement my own protected FSAVE functionality.

[MoMo]

By default, the contents of fasve are saved in /var/ftp/usrflash/Project/Configuration/pp_custom_save.tpl, so they will be deleted when you use the "$$$***" command.

If you set Sys.fastsavemode=1, then when you use the fsave command, it will be saved to the /usr/opt/ directory and will not be affected by "$$$***".

This feature requires firmware version greater than 2.5.4.0.

[Ian Nicholson]

5 hours ago, MoMo said:

By default, the contents of fasve are saved in /var/ftp/usrflash/Project/Configuration/pp_custom_save.tpl, so they will be deleted when you use the "$$$***" command.

If you set Sys.fastsavemode=1, then when you use the fsave command, it will be saved to the /usr/opt/ directory and will not be affected by "$$$***".

This feature requires firmware version greater than 2.5.4.0.

That's great info, thx! Do you know when 2.5.4.0 was released?

[MoMo]

V2.5.4 Maintenance Release Updates (Jan 2020)

[MoMo]

1 hour ago, Ian Nicholson said:

That's great info, thx! Do you know when 2.5.4.0 was released?

In fact, there is a more elegant way to realize your wish.

You can use terminal software like Tabby to connect to PPMAC, and then use "mount -o remount,rw /opt/user" to remove the write protection.

Then use Tabby's SFTP to upload your configuration file to opt/user

Just drag the configuration file directly into it

Then use the command "mount -o remount,ro /opt/user" to restore write protection.

 

Use such a PLC program to load your configuration when powering on.

The user folder will only exist in firmware versions after 2.5.4.0.

Using this method you can permanently solidify your parameter settings in the controller.

Since PPMAC is a general-purpose computer, there are many ways to achieve your wishes, even through remote network methods.

 

If I were to do it, I might use Winfrom to write a small software to deploy the configuration file. In this way, workers only need to click a button to complete all the previous steps.

Edited Wednesday at 02:36 PM by MoMo

[Ian Nicholson]

6 minutes ago, MoMo said:

In fact, there is a more elegant way to realize your wish.

You can use terminal software like Tabby to connect to PPMAC, and then use "mount -o remount,rw /opt/user" to remove the write protection.

Then use Tabby's SFTP to upload your configuration file to opt/user

Just drag the configuration file directly into it

Then use the command "mount -o remount,ro /opt/user" to restore write protection.

 

Use such a PLC program to load your configuration when powering on.

The user folder will only exist in firmware versions after 2.5.4.0.

Using this method you can permanently solidify your parameter settings in the controller.

I like the freedom that having a Linux-based PMAC brings! I'm concerned that the level of expertise required for this method will start to exclude some people (other techs), and brings a certain risk to the PPMAC filesystem. For our purposes I think the FSAVE and Sys.fastsavemode=1 will be plenty, but I'll ponder this and see if there would be benefits to going the above route.

[MoMo]

If you press the download button, the program will download the setup0.txt  setup1.txt setup2.txt setup3.txt setup4.txt setup5.txt files in the directory to the above directory.

open plc 1
system "gpascii -2 -i/opt/user/setup0.txt"
disable plc 1
close

You can then use the above PLC program loaded in this file.
If you click the clean button, the files will be deleted from the controller.

All programs do not use PDK, so you do not need to pay for any communication library. The connection uses the ssh.net communication library, a free open source communication library.

 

Release.zip

Edited Wednesday at 03:04 PM by MoMo

[Ian Nicholson]

6 hours ago, MoMo said:

If you press the download button, the program will download the setup0.txt  setup1.txt setup2.txt setup3.txt setup4.txt setup5.txt files in the directory to the above directory.

open plc 1
system "gpascii -2 -i/opt/user/setup0.txt"
disable plc 1
close

You can then use the above PLC program loaded in this file.
If you click the clean button, the files will be deleted from the controller.

All programs do not use PDK, so you do not need to pay for any communication library. The connection uses the ssh.net communication library, a free open source communication library.

 

Release.zip 189.28 kB · 0 downloads

Thanks! I'll look into this. I've implemented something vaguely similar to this using the standard FSAVE variables I chose, within our LabVIEW HMI app; it's use is currently to restore calibration parameters from a previous point in time in case someone is muddling but the intention is to eventually allow commissioning through a similar method.

I'll have to look into the Renci SSH.NET library to see if it offers any improvements over libssh2 that we currently use. I've also occasionally used Windows 11 Terminal to SSH into a CK3M to inspect a variable; powerful stuff.