Hi there,
I'm sorry for being still in troubles despite your help. I fixed the problems mentioned above, I remapped all inputs, revised all IOSYS, config and my global variable mapping etc files that had variables and actions related to my IOs but I ended up with all stuff not working at all. Finally, I had to go back to my initial software and hardware set up to get the robot working again. Now I have to start again from scratch.
So my first question is if I can physically install my analog module anywhere between my other IO modules replacing one of them or if it has to be installed in a specific position (i.e. before my digital input module, last of input modules but befor the digital outpus, after all input and output modules.
Second, the signal coming from the potentiometer goes in the VIN of the module, but do I have to connect the GND IN of the module together with the ground going to the potentiometer?
Thanks,
Marco
How to trigger actions with Stop Program Button KRC2
-
Marco -
June 6, 2015 at 7:48 PM -
Thread is marked as Resolved.
-
-
That depends entirely on the I/O hardware you're using. Every brand and model I've ever used has had its own specific rules for how to add/insert new I/O, and none of them were entirely the same. There's also differences in the way that different brands map the physical addresses to the byte addresses -- they don't always follow the same order. You'll need to dig deep into the documentation for your specific I/O hardware.
-
I there,
finally I made it. First, I had to install the analogue module after all digital in and out modules. Second I finally got that the analogue module occupies the first 2 bytes of the Devicnet memory, so I had to change all bytes offset of all digital inputs I had already wrote in my IOsys, but, and this is what I was totally missing, the index of the digital input do not change even if I change the offset due to the presence of the analogue inputs. Last time I changed both offsets and indexes; this is why I had a mess. So $IN[4] is still $IN[4] even if I have the analogue modules connected. What changes is that INB0 is not INB0=5,0 anymore but INB0=5,4 (the 2 analogue occupy the first two 16 bit slots). I don't know if my description is totally correct but it works! Now I can go ahead with the programming of my secondary remote pendant for milling control.
Thank you guys once more.
Best,
Marco -
Hi there,
I'm still working on the secondary remote pendant. I now have my $config file with a R_OVERRIDE_IN variable showing the potentiometer value from 0.000 to 1.000 in the Variable Monitor Display correctly. I also have a main SUB file in my program folder with all variables and stuff to check (like emergency buttons state, spindle state etc..) and in there I declared a new variable R_OVERRIDE_OUT = 100*R_OVERRIDE_IN to get the new value from 1 to 100 for the $OV_PRO. So now I'm trying to link it to the $OV_PRO to be able to control robot speed in auto mode form the potentiometer, but I did not succeed yet. I found another post on the forum about robotoverride suggesting to edit the SPS, I placed in there my R_OVERRIDE_OUT formula but I get an error.
Any suggestion? I also see that $OV_PRO is an INT while I have a value with 3 decimals? Is this also a problem?
Very Best,
Marco -
login as expert, open SPS, scroll down to USER SPS fold and expand it.
inside it type in something like:$OV_PRO=100*R_OVERRIDE_IN
-
Hi there,
it has been a very busy period and finally I have some hours to get back to my project. So I did what you suggested and I solved the errors I was getting. However, I tested to potentiometer with a simple program and it did not affect robot speed at all.In my config I have: Signal R_OVERRIDE_IN $ANIN [1]
In my SPS (under user plc fold) I have: $OV_PRO = 100*R_OVERRIDE_IN
In my SUB inside program files with all security loops etc I have: DECL INT R_OVERRIDE_OUT and R_OVERRIDE_OUT = 100*R_OVERRIDE_IN, which I'm actually not using.I suppose it is a variables issue
Any Idea of what I'm doing wrong?
Best,
Marco -
Well, the first thing to do is pull up $ANIN1 in the I/O monitor and see if it changes as you turn the potentiometer.
-
Yes it is working. I see values changing from 0.000 to 1.000.
-
Okay, second step would be to monitor R_OVERRIDE_IN the same way. See if it follows the pot and $ANIN[1].
If that works, instead of $OV_PRO, set up your own INT variable in the SPS in $OV_PRO's place and monitor that variable, to see if you get 1-100 as you turn the pot.
-
The R_OVERRIDE_IN works fine showing values 0.000 to 1.000, but If I monitor the R_OVERRIDE_OUT, which is declared as INT in my sub in order to get rid of the last decimal when I do the operation 100 * R_OVERRIDE IN I (i.e. 0.275 * 100 = 27), I do not see any value in the variable monitor. So I guess the operation has something wrong and this is way it is also not working when I set $OV_PRO = 100*R_OVERRIDE_IN in the SPS
But I do not understand what is wrong. -
Ah. It's the way that KRL handles REAL/INT conversions. If you assign an Real value to an Int variable, the variable does not get rounded, but truncated. And if you multiply a Real by an Int, the result will be a truncated Int. So:
0.5 * 100 = 0
0.5* 100.0 = 501.5 * 100 = 1
1.5 * 100.0 = 150It looks very strange (and kind of is), but it actually allows you to do things like check if a value is even or odd, and other math tricks, where KRL lacks commands or functions for. There's no KRL equivalent of the C function to divide two numbers and take the remainder, but by juggling REALs and their truncated-INT equivalents in KRL, you can achieve the same effect.
-
not exactly....
when REAL value is assigned to INT variable, it is rounded to a nearest integer value.
example
when performing multiplication, addition or subtraction, you get values as expected (only division is somewhat tricky and if dividing INT/INT you get value that is truncated)
Code
Display MoreDECL INT N DECL REAL F F=1.5 ; F is 1.5 N=3.3 ; N is 3 F= F*100 ; F=150.0 N= N*100; N=300 ;... F=1.5 ; F is 1.5 N=3.3 ; N is 3 F=100*3.3 ; F is 330.0 F=100*N ; F is 300.0 since N was previously rounded down to 3 by assignment N= 3.3*100 ; N is 330 because expression is first completely evaluated and THEN assigned to N (and during assignment, value may be rounded if needed) N= 3.3 ; N becomes 3 again since rounded by assignment N= N*100 ; N becomes 300 since 3*100 is 300
so if you are sending value in range 0.0 - 1.0 to an integer variable, you will get result either 0 (when <0.5) or 1 (when>=0.5).
and when such value is multiplied by 100 you get either 0 or 100 but nothing in between.so your R_OVERRIDE_IN must be declared as REAL type, not as integer.
-
-
So what do you suggest? I have no idea where to put my hands now.
-
Nope. And I am sorry but ... I was right...
You are just combining both into one line of code and then drawing wrong conclusions...Rounding and truncation are two different things and both occur in different sets of circuimstances.
ROUNDING = finding nearest value that fits into target variable. Result can be rounding up or rounded rown (value after decimal point is taken into consideration):
CodeDECL INT N ; declared integer N=3.3 ; N is 3, rounded down since first digit after decimal place is 3 (which is less than 5) N=3.6 ; N is 4, rounded up since first digits after decimal place is 6 (which is >=5)
TRUNCATION = removing all digits after decimal point regardless of their value.
CodeDECL REAL F F = 15/3.0 ; F is 3.75 since this is FLOATING POINT division F = 15/3 ; this is now integer division so result is TRUNCATED and 0.75 is discarded. F is 3.0 because of typecasting of integer result (3) into floating point (3.0)
Division is of FLOATING POINT type IFF (if and only if) at least one of the arguments is floating point type.
When both sides are integers (INT/INT), then INTEGER division is performed.
INTEGER division causes truncation, FLOATING POINT division does not.ASSIGNING integer to real value performs TYPE CASTING and 14 (INT) is converted to 14.0 (REAL) in your examples.
ASSINGING real to integer value performs TYPE CASTING as well and this is where rounding occurs (only during assugnment).
Note that if you have a complex expression, it will be processed in two steps:
1. solve expression (computaiton part). This is allways the same (*)
2. result of solution obtained in previous step is assigned to a variable (**)(*) result is the same regardless of type of target variable used in step2 (result can be any type regardless of type of target variable)
(**) result is type casted if target variable is not matching result (for example if REAL value is to be assigned to INT variable, it is rounded)this is also easy to test:
Code
Display MoreDECL INT N ; N is an integer variable DECL REAL F ; F is a floating point variable N=13/4 ; integer division so 3.333333 is truncated to 3 (before assignement) N=15/4 ; =integer division so 3.75 is truncated to 3 (before assignment). note if it was rounding, 3.75 would be converted to 4 but that is [b]not [/b] the case. N=13.0/4 ; floating point division so result is 3.3333; however result is rounded to 3 during assignment (= sign) since typecasting takes place. N=13/4.0 ; floating point division so result is 3.3333; however result is rounded to 3 during assignment (= sign) since typecasting takes place. F=13/4 ; integer division so 3.333333 is truncated to 3 (before assignement). during assignment (= sign) value is converted to floating point (3.0) F=15/4 ; =integer division so 3.75 is truncated to 3 (before assignment). during assignment (= sign) value is converted to floating point (3.0) F=13.0/4 ; floating point division so result is 3.3333; no typecasting takes place. F=13/4.0 ; floating point division so result is 3.75; no typecasting takes place.
Edit:
Marco:your R_OVERRIDE_IN must be declared as REAL type, not as integer.
if it is declared and integer and you monitor it (single variable monitor) you will see that values get rounded up (to 1) or down (to 0) when analog input is closer to 1 or 0.
if you declare R_OVERRITE_IN as REAL, you will see range of values 0.000 - 1.000 which is what you want. -
Hm! It would appear I was wrong. I must've always been doing equations, and never tried (until now) doing a "IntVar = FloatValue" type of assignment. Which, you're right, does perform rounding.
-
This extensive explanation is gonna be useful, but I'm worried we are taking the tangent...
My R_OVERRIDE IN is a signal coming form a potentiometer as an $ANIN and it works fine; I already see proper values in the variable monitor ranging from 0.000 to 1.000. I need to transform this value into an input for the $OV_PRO value to control speed during a program from the potentiometer.
-First, as suggested earlier, I wrote in the SPS a line of code with $OV_PRO = 100 * R_OVERRIDE_IN but it didn't work.
-Then, I created a new variable in a SUB file in my program folder (where there are all other controls running all the time): DECL INT R_OVERRIDE_OUT = 100 * R_OVERRIDE_IN; it didn't work either, the variable monitor do not show any value at all.
-Now, still in my SUB, I tried DECL REAL R_OVERRIDE_OUT = 100*R_OVERRIDE_IN, to see if ,at least, I can see the result of the multiplication, but still nothing.As OV_PRO value goes from 0 to 100, I only need to understand how to map the value of the potentiometer to the necessary input range for the $OV_PRO.
It is this step that is causing troubles. There must be a step in-between that I'm missing.Hopefully you still have energies to hellp me
-
your code cannot be just anywhere in SPS, it must be inside the loop, preferably inside USER PLC fold. also SPS has to be error free and running. if the code is not processed, it will have no effect.
of course you can also use analog input there:
$OV_PRO=100*$ANIN[1] -
Still no result.
My SPS SUB is running.
My monitor shows the R_OVERRIDE_IN.
I also did a cold reboot.
I attached a screen shot. -
i cannot help unless you post archive of your robot... there must be something else overwriting $OV_PRO and it is probably in SPS loop - after your code.
Btw. i just tested it in my OficeLite and on real KRC2 controller - it of course it works on both.
instead of analog input i declared variable in $CONFIG.DAT:DECL REAL TEST = 0.25 ; simulated analog input
then added in SPS loop:
$OV_PRO = 100*TEST
When i change value of TEST variable, POV changes as expected (25% in this case) as long as SPS is running.
-