I just ran into a small snag on the EPIC while writing files. I noticed that a particular file was not updating, it’s something that should be over-written at some interval, but it wasn’t doing so.
I tracked this down, and found that I was receiving an undocumented error code on the ‘OpenOutgoingCommunication’ command - error -408. I’m going to go out on a limb here, and guess that this is some sort of permissions error, because of my further findings:
Through testing and trial-and-error, I found that if I deleted the file using groov Manage, the PAC program is now able to write it, and rewrite it as expected. It’s only going to throw that error if the file was written to the controller by dropping it into the unsecured folder using groov Manage. I’m guessing that groov Manage sets the linux permissions in some way that the PAC program is not allowed to now overwrite the file.
So, what I need to be sure of (at least for now) is that my techs aren’t sending that particular file through groov Manage. Trouble I have is that this file is used to load setpoints on the machine for initial commissioning, so they have to load it once, use it, then remember to delete it so it can be rewritten from then on. A bit of a chore.
Thanks very much for the detailed post.
You are correct. Its a Linux permissions thing.
The PAC Control Engine user is different from the groov Manage user and they each have different levels of write access to the file system.
What you encountered is pretty well known and I will have to reach out to the docs people and make sure it gets in the documentation (I honestly thought it was, but I can’t find where, so if its that hard, its missing!)
Can you tell me if there’s going to be a fix for this? It seems counter-intuitive to say ‘unsecured’, yet to secure them so the program isn’t allowed to overwrite things.
Maybe I wasn’t clear… I find this to be a real problem, because of the following scenario, which is what I’ve got… The file in question is a setpoints file- it can be read by the PAC program, and also (over)written by the PAC program. It’s intended to save setpoints that may be lost if the memory gets cleared by accident, and to be backed up off-controller so if the controller fails we can reload from these setpoints. As part of commissioning, we often drop this file onboard a new controller so we get all the setpoints ‘pre-loaded’, which saves a ton of time. Trouble is, if we drop this file on the unit at commissioning, then we are now unable to update it. Knowing the error message, I can now call out the fact that it’s unable to write, but it’s not able to fix the problem- it takes someone logging in and manually deleting the file to get it working again.
I’d rather see the PAC program given write authority in the unsecured folder, which would make this issue disappear forever.
under the About section, it says ‘System Version 1.4.3-b130’. Think that’s the version you’re asking. The KB article isn’t really applicable- I see the file fine, and can read it just great. I just can’t overwrite it from the PAC program if it’s been written with groov Manage, as I’m sure groov Manage has higher permissions.
I dealt with this about 3 months back and made subroutines that would overcome this issue and write back to the same file in the unsecured Epic files.RECIPE_IMPORT_EXPORT.zip (4.4 KB)
Oh I forgot the other sub to read from controller. The attached has them both. The sub tricks the PRI thinking it is a new file since it is case sensitive and changes it back and forth.RECIPE_IMPORT_EXPORT.zip (8.3 KB)
