TESTEQ IP1[300] 1 OP2 explanation

Later version of firmware will allow comments - I believe using ; will delimit them.
 
You can't "END" a subroutine, it needs a return.
You can't "END" from nested subroutines for the same reason. You'll exhaust the stack in no time, and random (and certainly not "good") things will happen.
You can't set URAM values in your code, as earlier stated (memory write-cycle life)
 
TY RossW,
 
Oops - the embedded END should have been RETURNS 
That said, would the embedded RET be OK?
Also, the code isn't changing the URAM values - as mentioned, I am doing that manually via GUI.
That said, does code look like it should work?
I made the changes in the original post, changing END to RET (which was a silly mistake). But quickly checked sample program code and realized: RET is not actually needed as it would be in other program languages. Does the RET stop looping action of timed operations?
 
So, then I have three questions:
1- Does code look acceptable
2- do RET statements prevent looping
3- are the RET needed or inappropriately placed?

RAiner
 
rfeyer said:
TY RossW,
 
Oops - the embedded END should have been RETURNS 
That said, would the embedded RET be OK?
Also, the code isn't changing the URAM values - as mentioned, I am doing that manually via GUI.
That said, does code look like it should work?
I made the changes in the original post, changing END to RET (which was a silly mistake). But quickly checked sample program code and realized: RET is not actually needed as it would be in other program languages. Does the RET stop looping action of timed operations?
 
So, then I have three questions:
1- Does code look acceptable
2- do RET statements prevent looping
3- are the RET needed or inappropriately placed?

RAiner
 
 
I think you would be a client for a graphical programming user interface having WYSIWYG and I would join you;-)
 
rfeyer said:
Also, the code isn't changing the URAM values - as mentioned, I am doing that manually via GUI.
 
Oh? I must have mis-interpreted your intention here then:
 
endall:
     ram1 0
     OP1 0
     OP2 0
     URAM1 0     <---- I inferred you were trying to set URAM1 to 0 here but messed up the syntax, like the 3 lines above?
RET
 
RossW
You are absolutely corect - that clearance of URAM was done in error/ haste - should not be done.
The reason I AM using URAM is so I can change it manually.
 
TY for pointing it out.
 
Is the rest of code acceptable/ logical?

Rainer
 
Efried - a GUI of course would be fine, but we do not have one and the board is great so, learning the language suits me fine
 
I am stuck - can not figure out how to make a loop subroutine which activates by manually chaning either a UROM or OP but have the loop end electronically
 
I am planning on either changing the value of a UROM or OP and have it go through the above code, simplified idea of it below:
START    
TSTEQ OP1 1  
CALLSUB RAISE   
TSTEQ OP2 1  
CALLSUB LOWER   
END    
 
RAISE:
TSTEQ OP1[1000] 1  
SET OP1 0  
RET    
 
LOWER:
TSTEQ OP2[500] 1  
SET OP2 0  
TSTEQ OP2[500] 0  
SET OP2 1  
TSTEQ OP2[500] 1  
SET OP2 0  
RET  
 
How do I stay in the LOWER routine without the (after Start) code stopping re-entry into the subroutine LOWER?

Rainer
 
You can set a VAR or RAM from UROM at code outside your LOWER subroutine. Then inside LOWER routine, check against UROM and that stored value, if they did not match, GOTO another place you handle that logic, or CALLSUB another sub routine to handle that.
 
TY support,
I tried doing that, but: UROM can not be changed from inside.
If you look at my initial code above, there I used UROM, but, it ran endlessly.
If there was a way to loop inside the subroutine (again, as I tried in the expanded PLC above) then this would be somewhat easy.
Any thoughts?
Rainer
 
I thought you would manually set UROM then switch the logic based on that value.
If you really like to store a value, you can use I2C or SPI bus to write to an external EEPROM chip.  If that external chip is worn, you can simply replace that without change anything on Webcontrol and other wiring.
 
TY Support,
That is something I will have to leave on the back burner for now.
RossW actually did help a lot actually understanding two aspects of the sample code which now allows me to  utilize it straight without having to use UROM.
 
Your info is definately appreciated,
Rainer
 
Back
Top