HELP: Mitsubishi FX5UC - Password Protect SDT/Global Registers

Hi,

I'm currently in the process of locking down a program, I have managed to set passwords for FB's and WS but can't seem to find a way of locking structured data type and global registers.

just wondering if anyone knows a way of doing this?

Why do you need to lock down global registers? You can lock the total program so it cannot be edited only viewed or not and of course protect the plc from reading or writing

Hi

It is so nobody can change the devices, we are developing a base package HMI / PLC combo and have put a lot of time into developing a good userfriendly base but we don't want to allow others to take/modify what we have done.

Like I say, if you lock the plc they cannot upload or download. Do you intend giving them a copy of the protected code? if not then they cannot modify the structure in the file or in the plc, the only thing they may be able to do is modify the value in registers. I do not have an FX5 but locking the plc will stop them accessing it.
Personally, I think the excuse of locking a plc based on you do not want people to pinch your code is a poor one, I have been in this game for over 35 years and only protect code if the customer wants it (to stop their own people from messing it up). Most machine Mfr's or OEM's would rather write their own code than pirate others. If you think you can write code that no other professional can then you are mistaken. I sort of understand that as a machine Manufacturer you may want to protect your assets (or as many want hold the customer to ransom) but you will struggle to stop others copying a process without a patent and I cannot believe another machine manufacturer would want to try & decipher your code and use it, it would probably be quicker to re-write it.

Thanks for the response, I don't think I explain myself the best in what we want to do, we only want to lock down the base package, when we come to using the base package in a project we don't want to lock the application that belongs to the customer in the end, we want them to do whatever they want with there application but we would like to lock the parts that we have developed to make our lifes easier. so we would need to be able to lock specific parts of the PLC program

I assume you use the structured data types in your code, so why would you need to protect them, basically if they mess it up then they will need you to sort it out. You can protect POU's as required so I don't really see a problem.

If you are trying to preserve a set value for a specific word then don't rule out someone writing a HMI program to write whatever they want to the word. Even with a protected program it will let a HMI write new values.

Depending on how many specific words you are trying to secure it might be to (early in the scan before it's used) MOVP K500 D506 to force D506 to be 500.

Aabeck said:

Depending on how many specific words you are trying to secure it might be to (early in the scan before it's used) MOVP K500 D506 to force D506 to be 500.

Click to expand...

I have used this method a few times before, not in mitsubishi but other brands.
To freeze data blocks that can be changed from the HMI or other areas that the user can access.
When i want to allow a change to this area from the user area i normally bury a bit to open up these blocks to be changed.

Don't see the point of copying a fixed value into a register at start up unless it will be changed during program running. why not just hard code a fixed value, other point if it is to be changed via the HMI, put it on a high level password not disclosed to the customer.
The only time I move fixed values on start up if for some reason (this should never happen) if the variable may change during run and for some reason has been forced outside limits this is often used in indirect addressing one example if for some reason setting a pointer to a recipe i.e. 1-20 and either the code was downloaded to a new processor without init of variables i.e. pointer = 0 then force it to 1 so it is within the pointer range, this can save a trip to site.

parky said:

...if it is to be changed via the HMI, put it on a high level password not disclosed to the customer....

Click to expand...

I was thinking of the resourceful 3rd shift guy programming his own HMI to change a value he wants to change.

I have seen this happen. A 3rd shift worker had his own HMI and would program it for whatever PLC he wanted to connect to and have it change a single, or maybe 2, values in the PLC.

If the PLC gets a command from ANY HMI to change D506 it will not know the command is coming from a temporary PLC and change it.

Also, years back worked on PLC 5 lines with QuarTech HMIs that had pre-programmed into them a screen (something like sceen #768) that had entries for Address & Value that you could enter 7:5, 32767 and it would write 32767 to N7:5. The screen could be entered by typing the number in GoToScreen, or (on these lines) there was a momentary toggle switch in the panel that sent the HMI to that screen. That was a very dangerous screen and I never liked it being present as anyone could change any integer, Real or word of bits, and if under value you entered the value for .Pre or .Acc (4:6.10) you could change a timer or counter value without any checks or confirmations.

I found a photo I took of it in my archives of those lines:

I totally agree, if pre-set values are going to be changed Via an HMI then perhaps extra checks within the plc may be required, as you say there is no way you can stop resourceful people from fudging these systems, If you read the original post he stated they had put a lot of time etc. and did not want it poaching, a later post stated he was stating that this is standard and did not want it changing, which do you think is the real post. I do not believe in protecting anything I wrote unless specifically requested by the customer and happily will share it. I understand people protecting their investment unfortunately many use this as blackmail (I have seen this over & over again). I consider PLC coding as implementing a set of pre-defined instructions available to the programmer and in reality they are not creating anything unique that many others could create without breaking into a sweat. Again I re-iterate that in most cases it is easier to write you own code than try & decipher and use with confidence others (unless well documented).