debugging/monitoring, especially gx developer

qvolker · Aug 4, 2005

hi,

i made a mistake lately, writing to an indirectly addressed device in a mitsubishi q series program using an incorrectly initialised index register. since i couldn't just use a search function to locate the operation that was setting it, it took me quite a while to find.

now, it would be handy, if the monitoring software (gx developer in this case) would have a function that even basic debuggers on computers have: to watch some device and tell, where (which program line) it's state/contents has been changed. unfortunately i couldn't really find any information on that in the sad manuals. next i called up the support, but the guy was clueless (it took me half an hour to explain what i wanted to accomplish) in the end he recommended using interrupts but couldn't tell me how to do so.

my questions:
* is it really that uncommon to monitor device changes in PLCs in general and especially on mitsubishi's q series and

* how can you accomplish it?

* debugging inside FBs: that should be theoretically possible, since the FB gets actually inserted in the program that is using it, right? how do i go about that?

* can i find the current line number/instruction number and the program that is currently being executed somewhere?

* can i somehow trigger an exception / interrupt after each step or when some device changes?

* any hints on debugging? i am programming computers for ages but are quite new to PLCs...

thanks in advance, best regards,
Volker.

ushidayo · Aug 4, 2005

When the wrong device was written to, did the PLC go into fault mode? If it didn't then there is very little that any PLC monitor can tell you about the state of the program when this occurred.

Unlike a "computer" program, with PLCs you can't access program memory with ladder instructions (e.g. using a move instruction to write data into a memory area reserved for the program itself). This means that PLCs should be less prone to programming bugs causing the program to corrupt itself.

If I was in your shoes I would take the following course of action if I found that a device was being written to by mistake:

1. Search for all references to the device address (to my knowledge, all PLC program editors have this function).

2. If it doesn't seem that the instructions found in the previous search were the cause of the problem. I would check if an operator interface or another PLC connected to the PLC was writing to that address.

3. If that wasn't the problem then I would search for all indirect or indexed instructions that might have caused the over-write.

4. If there was a lot of indexed/indirect addressing. I might set traps after the indexed/indirect instruction to catch any reference to the problem device. If you set the trap to fault the program then you should be able to see from the PLC diagnostic function where the program halted (i.e. which trap was sprung).

As somebody who has programmed computers for years, I guess you are aware of the importance of range checking. Adding some range checks before indexed addressing might have prevented the problem. Also GX Developer should allow you to view the contents of an instance of a FB online.

Welcome to the world of PLC programming, we do things different.

qvolker · Aug 9, 2005

ushidayo said:
When the wrong device was written to, did the PLC go into fault mode? If it didn't then there is very little that any PLC monitor can tell you about the state of the program when this occurred.[/QOUTE]

no, unfortunately it didn't.

ushidayo said:

Unlike a "computer" program, with PLCs you can't access program memory with ladder instructions (e.g. using a move instruction to write data into a memory area reserved for the program itself). This means that PLCs should be less prone to programming bugs causing the program to corrupt itself.

Click to expand...

i don't want to write self-modifying code or access the program itself.
what i want is, to get some kind of report: which program step changed my output.

ushidayo said:

3. If that wasn't the problem then I would search for all indirect or indexed instructions that might have caused the over-write.

4. If there was a lot of indexed/indirect addressing. I might set traps after the indexed/indirect instruction to catch any reference to the problem device. If you set the trap to fault the program then you should be able to see from the PLC diagnostic function where the program halted (i.e. which trap was sprung).

Click to expand...

i did the latter (actually i didn't trap my program but monitored the device before and after) which worked fine. problem is that that procedure is quite tedious. since it should be technically not that difficult to implement some kind of feedback on which program step changed a particular device, i just thought i didn't find the appropriate option/menu (like device forcing being hidden away in 'online/debug/device test'). i'm currently thinking about a more comfortable way (with interrupts) - any suggestions?

ushidayo said:

As somebody who has programmed computers for years, I guess you are aware of the importance of range checking. Adding some range checks before indexed addressing might have prevented the problem. Also GX Developer should allow you to view the contents of an instance of a FB online.

Welcome to the world of PLC programming, we do things different.

Click to expand...

hmm. yes. i think the overhead might not be acceptable in that case, though... the program would grow by at least 30%, i think... actually the mistake was _really_that__stupid_(tm), i wouldn't have used range checking anyway... it was:

Code:

----||--+--[MOV special_address z2] cond |.... +--------------------(Y0Z2) which should of course be ----||-----[MOV special_address z2] always ----||-----------------------(Y0Z2) cond ....

a very special case of 'bad range': an uninitialised pointer. this program piece then reset an output that was set in another program before, since the latter used the same index register. now i reset index registers that are used many times, so at least in the case of uninitialised use, it is a well defined address, which i can monitor.

about the FB monitoring, yes you are right, it works. thanks! that's going to save me a lot of time. it didn't work, when i tried, though - and even the mitsubishi hotline couldn't tell me how i would go about monitoring FBs...

ok, again, thanks for your input on this. does anybody else debug programs?

best regards,
Volker.

debugging/monitoring, especially gx developer

qvolker

Member

ushidayo

Member

qvolker

Member

Similar Topics