additional PLC help

[rfeyer]

Hi all,
 
I would love to hearn more about PLC language.
My question: Are there any additional help resources such as books etc where I can read more? And, are there additional commands?

I am probably being a pain with my continued questioning so I am hoping I have some resource I can read and study to reduce the number of anoying questions,
TY in advance,
Rainer
 

 

[mikefamig]

I don't know the language myself but this looks like a good place to start
 
http://www.ladder-logic.com/

 

[rossw]

Umm, no. The CAI Webcontrol is not programmed in Ladder.

 

[rfeyer]

OK, then there is no other source for learning the language.
Do you all mind if I continue asking questions? Maybe looking at some of the samples I do not understand?
 
Question 1 - sample code 6
  BNZ IP1 start -   I understand we can call a subroutine with checking for NZ - but, this really says: If IP1 is 1, then go to start - but, there is no subroutine start, so, would it not just be an indefinate redundancy?
 
Question 2 - Example code 7
  START
CALLSUB LIGHTS_GO
 
then ...

LIGHTS_GO:
SET OP1 0
SET OP2 0
SET OP3 1
RET
 
Nothing in this code seems to allow entry into any of the other subroutines. LIGHTS_GO sets OP's without calling subroutine, and, between START and END there is only a call to LIGHTS_GO and then subroutines?
 
Am just trying to understand so I can learn the coding, TY

Rainer

 

[Tschmidt]

I assume the WebControl language is homegrown by CAI so there is not going to be anything specific to WC.

I'd recommend finding something about assembly language programming, this will give you an idea about
general concepts, binary arithmetic, how to use registers, conditional branching etc.

I did a quick Google search for: "Assembly Language Tutorial" and got a lot of hits, even some Youtube
videos.

/tom

 

[rfeyer]

Well,
 
I have experience in coding with database languages such as Foxpro etc, as well as some VB. So, I am not that new to coding. Having to learn assembly language to use this little board I think is a little outside my comfort zone - then I would have to abandon the whole WC idea and think of something else
 
No way just to get help with the above for now? I am truly trying to learn this,

Rainer

 

[rossw]

I've managed to teach several people to use their WC boards effectively, or at least, I THIN I have
 
If I could give you some pointers, I'd say (in no particular order)
* Be completely clear in your mind WHAT YOU WANT TO DO.
* Take your time. Make notes, drawings and comments.
* Despite being "old school", flowcharts can really help you get your logic straight.
* If you don't already, learn to like coffee
 
Now, here's an actual example from a few years ago. It doesn't use all the modern webcontrol enhancements, like rotates, broken down word/byte/bit sized registers etc, but it should help you understand the basic principles.
 
This was to control some solar panel trackers. First, start off with a clear understanding of what it was going to have to control. A circuit helps!
http://webcontrol.rossw.net/samples/tracker-circuit.pdf
 
Once you understand what you're going to need to control, a flowchart helps you make sure you have the LOGIC right.
http://webcontrol.rossw.net/samples/tracker-flowchart.pdf
 
Creating the flowchart, making sure the logic is right, before you write any code, saves a lot of frustration. (The comments in red on the flowchart were added during coding. Labels help you keep track of where you are in your code). Identifying what registers you're using, what bits within them, etc, helps avoid silly mistakes of setting or resetting or using the wrong bits and having bizzare operational issues.
 
Finally, write, test, debug the code a little at a time, one "functional step" at a time. Don't bite off more than you can chew!
http://webcontrol.rossw.net/samples/tracker-code
 
(I can't guarantee that the code I've linked is exactly the same as the flowchart, they were for two different people at two different times and while close, may not exactly match - so apologies in advance for that)

 

[rfeyer]

Hey RossW,
 
no doubt I could learn a ton from you and others!
 
I may be very wrong, but I do really have an understanding of what I want to do and even make 'simple word' schematics before starting prgoram code.
I even do this when I use Foxro or DB.
 
My problem with this language is that there are some simple fact I do not understand - and those I had put into questions - until I understand those, all the prep work in the world will not help me.
 
I spent the last 2 days doing simply: Trial and error. But, I still do not understand the question I had asked: Most of all, I do not understand why and how subroutines are being utilized by the code without being called.

Today I used one of the example codes I listed on the other thread I posted, and simply changed it so I would have 
 
START
   TSTEQ VAR1 5
END

some_Routine:
  some code
RET
 
AND, law and behold, the subroutine was activated (I don't have the code anymore). Any other language I know needs a call to subroutine.
 
Then I dissected the sample code for traffic lights (also listed in a thread) and noted- subroutines are not called for, somehow though they are accessed.  I just don't get this part.
 
I have a routine now which works, using tons of DELAY statements, but I do not like it. 

 

[rossw]

I spent the last 2 days doing simply: Trial and error. But, I still do not understand the question I had asked: Most of all, I do not understand why and how subroutines are being utilized by the code without being called.

 
Many people over-use subroutines (IMHO) and as a result over-complicate the code, making it difficult to understand what it's doing.
 
 

Today I used one of the example codes I listed on the other thread I posted, and simply changed it so I would have 
 
START
   TSTEQ VAR1 5
END

some_Routine:
  some code
RET
 
AND, law and behold, the subroutine was activated (I don't have the code anymore). Any other language I know needs a call to subroutine.

 
Your mistake here is that you've used the TSTEQ instruction without fully understanding how it works. Once you understand THAT, your mistake (and the explanation) become obvious. This is another case where "subroutine (mis)use" has added to your confusion.
 
 1.  TSTEQ (condition)
 2.  (executed only if true)
 3.  (program continues)
 
In your case above, if var1 was NOT 5 (ie, the test resulted in FALSE), the next instruction is skipped.
Here, the next instruction was "END".
The instruction PAST it was the first instruction of your subroutine!
 
So the simple misuse of the TSTEQ (by not putting SOMETHING, even it it was a NOP) meant that when the test condition was false, you were "running past the end of the program".
 

Then I dissected the sample code for traffic lights (also listed in a thread) and noted- subroutines are not called for, somehow though they are accessed.  I just don't get this part.
 
I have a routine now which works, using tons of DELAY statements, but I do not like it. 

 
 
Might I suggest that UNLESS your code has logical blocks that ARE repeated (and many programs simply DON'T!), that you ignore subroutines for now and program as much as possible in straight, linear code. Have a look at some of the principles in my example above - they are probably NOT "best practice" - it was done quickly, for a specific purpose, and without any intention of anyone else ever seeing it... so it's "warts and all"... but may give you some clues.

 

[rfeyer]

TY RossW,
I absolutely understand your explanation of the TSTEQ - certainly makes sense, another mistake of haste.
 
I will absolutely check your code - I am sure it will teach me a bunch, but I still do not understand how sample TRAFFIC LIGHT accesses subroutines without calling them?
 
I do have the program working, but would love to understand Sample TRAFFIC LIGHT.
Will check your code in a.m. - surely I will learn from it. TY

Rainer

 

[rfeyer]

Ah - I figured out my colundrum on the subroutine calling in example 7 (Traffic lights):
There are three subroutines inside START ... END. These are being evaluated continuously - the subroutines outside START .. END have to be called upon.
 
OK, understand that now.
 
Thanks for hanging in there with me,

Rainer

 

[rossw]

There are three subroutines inside START ... END. These are being evaluated continuously - the subroutines outside START .. END have to be called upon

 
Start and End are for the primary executable code loop. When the program hits "END" it re-starts at "START". Without an explicit GOTO (or END) at the end, the last instruction of the code block would naturally "run into" the first subroutine code...
 
Eg:
 

START
tsteq ip1 0
callsub off
tsteq ip1 1
callsub on


off:
set op1 0
ret

on:
set op1 1
ret
END

Here, the state of input 1 is tested. If it's 0, "off" is called. Next, input 1 is tested again. if it's 1, "on" is called.
After that, without an END or any other instruction, it runs straight into the off: subroutine, sets op1 off, then hits a "return" instruction. It has not been called, so has nothing on the stack, and will probably crash and reboot!
 
Correctly written would be like this:

START
tsteq ip1 0
callsub off
tsteq ip1 1
callsub on
END

off:
set op1 0
ret

on:
set op1 1
ret


 
Now, the code will keep looping testing ip1 and calling either on: or off: continuously.
 
(Yes, it's a stupid piece of code, but it's only to demonstrate how you might do it and what problems would happen if done wrong)

 

[rfeyer]

Not stupid at all, I do understand your teachings.
 
TY - that really does help.
 
If you do not mind, I will post what I have now (just need to clean it a little) tomorrow.

Rainer

 

[rfeyer]

Re-read again and have to say that is a really good explanation and saved me a lot of additional trial and error time - again, I had the problem of next line not being evaluated and END not being interpreted.
WOuld it help future WC PLC newbies (incl myself) to have a little PLC coding FYI sub forum?
There are tons of tidbits that are not available to read anywhere. Just a thought!

Rainer

 

[CAI_Support]

If you could summarize what you think helpful, put them into an article, we can circulate it with Ross and others, then we can take that and put on our web site, so that all can benefit from it.