Unitronics provides a full line of the most easily programmed Servo Drives, Motors, Actuators, & VFDs on the planet. This is the place to ask all of your Motion questions, whether you are using EtherCAT or CANopen!
🤦♂️ @Ausman you keep assuming I don't know what I am doing.... so, ok I will assume that you are NOT being arrogant and that maybe I was not clear on my previous statement due to a language barrier. of course, the LINEAR function will not stop at ar min or max value, that's the point of a linearization you gave the "initial" and "end values" to calculate the "slope" you don't expect that the linearization ends at certain values, I have that on consideration on my actual program, and I handle the min arnd max values in a particular way to prevent being out of range.
what I was trying to explain is that it overshoots over 7000, and the max value is 6000 which corresponds to 1800000 value on ML100, and at that point, since ML100 is near 1402000, then it couldn't be possible that the value at the output of LINZ is more than 6000 which is the value at 1800000 since 1402000 is less than 1800000 (you know... math).
but, let me give you more information, in the machine that I was running the program I noticed the issue looking at the data after an imminent failure involving this LINZ problem:
In this case, blue is what was sent to the analog output, in my program I have a condition to no update that value if it's out of range, I am not sending the max or min possible values if it is reached, instead I am just not updating the output (this is better for my particular process, and it helped in this situation because that spike after an hour the start of the ramp down would be very very bad, at least I got 1 HR of stable conditions after that )
anyway, as you see in the red line that I have drawn (which is what I concluded was happening in the background), at some point the value overshoot at above 7000, and then continue going down but 1 hr after that the value reached 6000 again (since was going down from 7000 now) since 6000 is within range, the output was updated again, that's what we see a "step" at the last 3 minutes, after that the system was shut down and then reset to the initial conditions, that's why it goes to 0 and 600 ( initial PW =600)
the orange line is what was desired to happen .... a linear and consistent ramp down from 6000 to 600 while counting downtime.
I am not going to upload any other program, I already did it.
It will be better if you could do a test and prove on your hardware, maybe is a v700 issue, maybe is a Visilogic Issue, who nows!
test different hardware could be good.
Start the countdown with these values
X2=0 (End value as the timer goes to 0)
X1=1800000 (timer value 5:00:00:00 loaded on ML)
Y2 = 6000
countdown to 0 and wait.
the overshoot happens near X= 1402000 (Not exactly at that number but I always override the timer at (3:55:00) and wait for until happens (a couple of minutes later)
I already did it counting down from 1800000 and the same happens.
Hi, i am using jz20-t40.
And my client want to be able to set min. and max. values for analog inputs (water probe).
I don't really know hot to make it.
When he pulls the water probe out of water he sets it as 0 (%) and puts it back into water to the point of which he will set it to be 100 (%).
Any help is very appriciated,
Thanks in advance.