Author Topic: Some apparent bugs  (Read 10523 times)

awt0m8

  • Newbie
  • Posts: 4
    • View Profile
Some apparent bugs
« on: February 08, 2006, 07:25:02 AM »
I have found what appear to be a couple of  bugs in TL5.33.

1) If you turn on protection for all of your custom functions, function 1 remains accessable.

2) A program which references the same custom function twice will compile and run, although the function runs every scan whatever the preceeding logic.(I know you shouldn't do this, but I did it accidentally when testing some logic)

3) If I program a free running timer, i.e. one which is activated by an NC contact the same name as the timer, contacts which reference the timer work when they preceed the timer, but not following. I know this is just a quirk, but with every other manufacturer's PLC the contact will remain on for one complete scan, so it works wherever it appears in the program.

support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3174
    • View Profile
    • Internet Programmable PLCs
Re:Some apparent bugs
« Reply #1 on: February 08, 2006, 09:10:21 AM »
Thanks for the feedback:

1) We will check on that. If this is a problem, maybe skip the use of function #1, or use it for initialization purpose only (such as attach it to 1st.Scan pulse to initialize variables or setup special I/Os).

2) Custom function is not like a relay or output coil and there is no race condition if it is executed at two different locations within a logic scan. You can also call another CF from within a CF so I guess the software did not object to having it appeared at two different locations. Some programmers find it more convenient to be able to execute the same CF at different parts of the program.

In fact, although TRiLOGI 5.33 will warn you if you have duplicate output coils, it actually allows you to overwrite it and continue compilation. The older TRiLOGI versions do not allow use of duplicate coils at all. However, we figure that some users may find it desirable to have duplicate coils within a ladder program and as long as the programmer understand the possibility of race condition in such circuits we decide to let the user has the choice.

3) This issue is discussed in the programmer's reference guide under Appendix 1 -.I.   Important Notes to Programmers of TRiLOGI Version 5.x. It was a legacy from the older days of H-series PLC and it was not changed when M-series PLC was developed. The solution is to always arrange the self-resetting timer AFTER all the ladder rung that uses that timer contact.
« Last Edit: February 08, 2006, 09:13:06 AM by support »
Email: support@triplc.com
Tel: 1-877-TRI-PLCS

awt0m8

  • Newbie
  • Posts: 4
    • View Profile
Re:Some apparent bugs
« Reply #2 on: February 09, 2006, 02:24:53 AM »
Thanks - I didn't notice the timer explanation in the programmers reference.

My point about the CF was that the manual specifically says (9-4 vi) that a CF may only appear once within the ladder diagram and that a compilation error will occur if a CF appears in more than one circuit. Are you saying that it can? Some of my programs would be more concise if I was able to do this,  but when I (accidentally) tried this, the CF operated on every scan, even though the rungs which activated it were both false.

support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3174
    • View Profile
    • Internet Programmable PLCs
Re:Some apparent bugs
« Reply #3 on: February 09, 2006, 09:21:37 AM »
I don't think the program would behave that way (CF being executed when the execution condition are both false).  Please check that the CF is not being called in other parts of the program:

When I tried a simple program:

     IN1          CF1
|----||--------{dCusF}
|
|     IN2          CF1
|----||--------{dCusF}


The compiler immediately complain that the CF1 has already been energized, but then it allows the option to override it. I have tested it on version 5.33. This is correct response.
Email: support@triplc.com
Tel: 1-877-TRI-PLCS