How do you upload the active strategy (strategy that is currently running) from a controller?
When I requested the Strategy file from a custormer I was provided with a backup in the format of a ZIP file. This leads me to believe that this was a archived file downloaded to the controller at a later time. Am I incorrect in this assumption?
What I am wanting is the current file as it is running on the controller. Is this posible or I can only get the archived version of the file?
When you download a new strategy into a controller, does it automatically create a zip file and archive it in the controller, or is the zip file created and downloaded in to the controller by the programmer?
IF they have opted to download the archive and store it in the controller itself (usually a good idea), and assuming no one has changed the file names, you’ll find that files downloaded to the system or archived on the PC have a timestamp as part of their name.
Here’s a one of each that I have and their corresponding DOS date/time:
03/29/2013 09:54 AM 40,947 CurvedDemo.Download.D03292013.T095457.zip
02/25/2013 04:44 PM 23,490 CurvedDemo.Archive.D02252013.T154417.zip
Do you have files in that format? (With the handy auto-generated Date and Time as part of the filename?)
Unfortunately that was not the answer I was looking for.
I neither want to do a back-up nor, do I want to create an Archive.
I simply want to get the “LATEST” as in currently running strategy, DIRECTLY from the controller.
Archived file in the controller could be obsolete as this is an archive created by the programmer when in PacControl. If Online edits were done at a later time without a complete download, archived file in the controller at this point in time becomes useless. If the programmer forgets to create a new archive file after doing online edits, then there is no way to know what is actually programmed in the controller.
This to me, seems like a scary way to implement a control system. That is, if there is no way to get the latest running code from a controller.
Now to the dated “DOWNLOAD” file that you mentioned. This is the file that I got from the customer.
Q1. Does this file gets created in the controller when a strategy is downloaded in to the controller?
If it is, then after an [B]online edit and without a full download[/B], is the file in the controller updated
automatically at that time?
Q2. Is this functionality (saving/retrieving a download file) available in SoftPac?
Q1. If, in pac control, you have the boxes ticked to make the archive and download it to the controller, then yes.
Q1.1 No. It only gets updated after a full download.
Q2. Yes. In this regard Softpac is just like a hardware controller. As far as retrieving a strategy from SoftPAC after its had online changes made to it, no, it really is the same as a hardware PAC. (Only much faster and can run up to 64 charts).
We have never had the ability to extract the strategy, and most of our customers/integrators/programmers prefer it that way. They dont want people pulling their code and messing with it.
I’m told that only a very few people use the on-line function. Personally I found it limited (cant create variables) so I never used it. I had to go ask a few people your question about the archiving of on-line changes.
Seems to be another of the PAC/PLC differences. Nether here nor there. Solid workarounds exist.
We have never had the ability to extract the strategy, and most of our customers/integrators/programmers prefer it that way. They dont want people pulling their code and messing with it.
Ben.
To me this seems a little scary in a sense that if the original programmer did not backup after an online change, or did not do an archive, or if he is no where to be found any longer, using an old back-up can bring a Plant/System to a screetching halt. This is because the only option available with a back-up uploaded from a controller is to download it back to the controller. if that was not a recent or an up to-date back-up, it will completely overwrite the existing strategy in the controller. Which is not good.
Anyway, that seems like a pretty big issue since there is no way to get the current strategy from the controller.
You are making the assumption that back-up in the controller is the latest. Regardless if online edits were done or not, Human error is alway’s a factor. There has to be someway to ensure / Compare current logic with a back-up to see if they are the same. It is common practice in the industry for someone to inherit a project from another person/company. I for one, really be worried from a safety standpoint in choosing a platform for a project, if there isn’t a way to determine or verify whats in the controller agains a back-up.
Anyhow, it is what it is with OPTO-22’s as it is today. So i guess its a moot point discussing it any further.
How about this. PAC control (later versions anyway) generates a checksum when the strategy code changes (and only when the code changes). This then is the reference to know whether the current strategy to be downloaded is different to the strategy in the controller, correct?
What about if there was an option in pac terminal to get the checksum of the currently running strategy and in PAC control an menu option to generate a checksum based on the current strategy. Compare and if they match then whalla! You have the current strategy, if not then it’s up to you what to do.
That will verify if you have the current Strategy.
But, isn’t it already there?
Because when you try to download a strategy in to the controller, it tells you if current (running) and the strtegy that you are trying to download are different. My point was to have the means to get the current strategy from the controller (without depending on an archived version), so new changes/modifications can be done to the current strategy without the fear of impacting existing operations. This way, if any modifications or updates cause any conflicts, you alway’s have the current strtegy that was directly downloaded from the controller (if this feature get’s implemented in the future) to re-load and minimize impacting operations.
I’m confused… If the checksums match then the strategy you have is the one thats running… So what if it’s an archive, you have the same strategy that is running in the controller. And if you are worried about changes causing problems, then you can always enable background downloads so you can swap back to the previous strategy if you hit an issue with the click of a button.
Nick,
As you know, when we were both working at the hospital, we just made the simple decision to never make online changes, and so we never had this issue.
I suspect that Skyfox is making the point that he is not in control of the other programmer. If the other programmer makes online changes and does not mention it, then the archive on both the controller and PC dont match whats in the controller.
What you would have to do is go into PAC Control and do a full compile (download not required) and then you will have an up-to-date version of the strategy that’s running in the controller.
Rather than doing that extra step, Skyfox is saying he wants to see the extra step of getting the strategy out of the controller.
Both achieve the same thing, its just a matter of what your used to.
Either way, your idea / concept of using the checksum to know if that extra step is required is pretty good.
So this begs the question of what all influences the checksum? Does the specific computer responsible for downloading the strategy impact the checksum? I’ve tried to download the exact same copy of a strategy from two different computers and been greeted by the checksum mismatch notice window. It’s quite common when I’m debugging a system on initial startup for me to be connected to the controller both via my laptop and the customer’s computer at the same time and I’ve learned to be really careful with this all.
Cool thanks ben. Got it. Maybe a strategy option of ‘disable online changes’ might help with this issue? But then who’s to say the other programmer might just uncheck it and away we go…
Ahh Arlin. I too ran into this issue. 2 computers debugging the same strategy unchanged. Resulted in different checksums. I emailed support over this and after some tooing and froing we found that it had to do with debug modes and subroutines. computer A had minimal debug and computer B has full debug (I think this is how it went, it’s been a while…), so when trying to debug a strategy a compile takes place (because of the different debug modes) and re generates a checksum resulting in a full download. I think we changed the both PAC controls to enable full debug and had no problems after that.
However this doesn’t answer your question, what determines the checksum?
