Fernando Castro
-
Posts
264 -
Joined
-
Last visited
-
Days Won
24
Content Type
Profiles
Forums
Gallery
Events
Blogs
Downloads
Articles
Media Demo
Posts posted by Fernando Castro
-
-
On my current application I am reading and writing recipe values from a data table, the recipe will have a variable number of steps, I already had the logic to navigate thru the recipe employing indexing numeric values in the screen ( 8 x 8 ) values of mixed data, some MI, ML, MB, and T.
The user requested a way to detect if there are some changes on the recipe that haven't been saved, and flag that row to ease the visibility of the changes made on the actual recipe. The values of the recipe also should be required to be saved only if you press the save button since the recipe should be able to be edited "live" while the process is running and you want to execute all the changes of each step at the same time.
so, I was wondering if the best way to do it will be using a struct to store the values of each row on the screen to a vector each time the screen is refreshed (that happen when the user touches the Next or Previous pages, that changes the indexed number + 8 and reads the Data table corresponding to that indexes values and stores it to the variables that are on the screen), then have another struct that stores the variables that are on the screen to a different vector, and compare those 2 vectors to detect if some value has been changed but not saved ( since the values on the data table will be different from the ones on the screen).
However, my main concern is to do that with 8 structs for the DB, 8 structs for the screen, or use 2 structs only (1 for Data table 1 for the screen) and make a "sweep" thru the 8th current indexed values. that second option will implicate reading the data table 8 times per program scan rather than reading 8 times per page update.
The main concern is rather to use more addresses in the memory or more time for each scan.
The other question that I have is what about using the Map function instead of a struct, there is a significant difference between those 2?or is there a way to detect if the user has touched some variable on the screen?
I personally dont want to keep using more vectors in the memory because at this point it may be difficult to keep track off all the memory addres that are being used
-
19 hours ago, Flex727 said:
This is correct. I, likewise, wish there was an option for integer registers during download like there is for timers. However, no integer register should be affected by a download. The only reason a register's value might change is due to ladder logic or a Power-Up value when the PLC is reset. Do you perhaps have some Power-Ups you're unaware of? Downloads sometimes reset the PLC then the Power-Up would take effect.
I have a case in which a particular setting was changed after downloading a new revision, I downloaded a beta version of the software on Friday, tested and worked ok. then keep adding features over the weekend (minor aesthetic changes requested by the user) then on Monday downloaded the newer version to test the process with the product. Long story short one of the settings on the calibration screen was changed and the pressure reading was off by 10 mbar which caused a very unstable process. I am not sure what happened since that particular MI can only be changed on the settings screen password protected, I guess that the MI on the project could be changed while running online on the plc that I use for testing. I did backed up the operands from the machine just for precaution before updating it but I did not think that I would be needing to restore it... the machine have not been running since Friday.
16 hours ago, kratmel said:For a long time i try to solve this problem.
Then my solution - use little different style of programming.
Then all my current application has default settings option (copy from datatable to user settings).
I use datatable - that it can be downloaded separately - used for change something default in process of project modification (save user settings to datatable as default option present on PLC via password).
If user need to change something (not recipie) - it have printed table with default and user changed settings. Then if something goes wrong - user can load default option -and change only small amount of parameter to start machines.
Maybe this idea need more time for programming but it help to restore and modify project whithout problems.
User settings for working application (all operand) - can be exported to txt file (Visilogic menu option) and saved in current downloaded project directory named as PLC serial# and time of modification.
I can compare the same format files with different operand settings. And load specific operands backup to PLC.
Maybe the online carries out some operands with it after you log off and if the project is saved some values too?
maybe the best way is: go online, export the operands, then download the project then import the operands again?
Anyway, the data table seems to be a tempting option to be able to manage the 200 devices in the future or at least have a subroutine for loading the default values, the other issue that I have is the standardization of the process 😑 having that option is pointless if every system had different settings due the nonstandard and manual adjustments that each one needs.
One of my professors used to say that a good design needs fewer adjustments -
4 hours ago, sgull said:
If you have done a lot of downloads to the PLC data can get stored in registers where you might not have intended.
Every now and again it is a good idea to download a blank program and do an initialize and reset.
then try your program again.
yes, I also have experienced that a lot!. I need to finish a new version of the software and update near 200 devices, but so far I haven't found a proper way to do a "backup" "update" and "restore" the old values for some settings, and also change others on each download.
It's crazy how I can do multiple downloads on the same device and same computer after some tests and have some settings now to be different. I mean most other brands ask you to keep or change values stored in memory, but unitronics seems to do, it only for timers... and also what about everything being persistent in the memory
I really like the hardware but the software Is so Confusing and frustrating!!
-
Probably no one else cares about it, but I found another bug in visiologic software. I don't know what happened but I edited one line of a program, then did the same change in another revision. both lines of the program are identical but one works the other does not.
I Just exported the working subroutine and replaced the nonworking one but. this kind of thing is not supposed to happen, at least is the first time that I see something like this on PLC software. 😤
I could be spending weeks trying to figure where was the problem
I looked at the STL view and seems that the data from the formulas is somehow different from one to another.100,7,42,3,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,66,10,0,0,0,5,15,200,66,0,0,6,5,37,0,0,0,2,255,0,0,0,0,1,255,0,0,0,0,5,5,35,0,0,0,6,15,200,66,0,0,40,40,68,101,115,105,114,101,41,42,49,48,48,47,77,77,95,80,69,82,95,82,69,86,41,42,83,84,69,80,95,80,69,82,95,82,69,86,47,49,48,48,79,80,66,0,10,0,5,0,37,0,5,0,35,0
vs100,7,42,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,66,10,0,0,0,5,37,100,0,0,0,6,5,37,0,0,0,2,255,0,0,0,0,1,255,0,0,0,0,5,5,35,0,0,0,6,37,100,0,0,0,40,40,68,101,115,105,114,101,41,42,49,48,48,47,77,77,95,80,69,82,95,82,69,86,41,42,83,84,69,80,95,80,69,82,95,82,69,86,47,49,48,48,79,80,66,0,10,0,5,0,37,0,5,0,35,0
I am not sure what those numbers mean but seems to be the formula translated to some decimal or other format.
anyway the formulas are the same in the text format
((Desire)*100/MM_PER_REV)*STEP_PER_REV/100
vs
((Desire)*100/MM_PER_REV)*STEP_PER_REV/100
or ... maybe the data was corrupted?
Feel free to take a look, even the software handles both same routines as being different if you try to download a projet that has one instead of the other.
P.D. I am not the original autor of this program, I just changed the result of the formula to be at MF instead of ML then because I needed more precision
-
11 hours ago, Flex727 said:
This is what I suspected all along. There is math behind the scenes to execute the linearization function. Trying to linearize very large numbers can result in a register overflow somewhere in that math. Use AlexUT's suggestion to divide the ML by 100. It's very simple, can be in the same ladder rung, and doesn't even require another operand.
🤔I get what you are saying, basically a decimal point shifting, I guess that's a good and simple solution... I solved it by doing the math with floatings and discarding the decimals which in a way is the same but yea the div seems simpler, I also thought that has to do with some calculation in the background.
anyway now I trust more in the math than in the linear function
-
On 6/18/2021 at 8:51 PM, Ausman said:
Not once have I said that. My responses are based on I don't know how much you know, as you are new here.
Don't forget I am not paid, I am a volunteer who has put in countless hours on this forum often explaining the same thing again and again to people who can't be bothered to look up help files or delve into the forum. Think how you might react if you were again asked how to turn on a light switch!
I have never had this issue myself, but I also only do linearisations on MIs. What happens if you convert your input numbers to MIs? Your needed output will still give the same accuracy on the smaller input range that is available with MIs. Using a counter based on SB13 will let you test this easily with your wanted time of 5 hours. I can't as I don't use 700s.
cheers, Aus
Fair enough @Ausman.
I doubt this issue will be happening with an MI since the MI can't store 1,402,000. however, maybe this will be happening with another set of numbers? that is difficult to know.
By the yaw ML are accepted by the LINEAR function that's what HELP file says:
You can convert values contained in the following operand types:
- Memory Integer (MI)
- Memory Long Integer (ML)
- Double Word (DW)
- System Operands:(SI) (SL) (SDW)
I am just reporting what I think could be a bug, also reported directly to unintronics support as soon as I spot it, if I am doing something wrong I will be glad to know, maybe I am just being stupid but so far I haven't found an explanation of why this is happening.
-
2 hours ago, AlexUT said:
This problem is "invented".
Vision timer has format:
HH:MM:SS.mm -> 5:00:00.00
Not X1=1800000 (timer value 5:00:00:00 loaded on ML)
Minimum timer interval for timer is 10 mSec.
For 5 hours interval you do not need precision of 10 mSec.
So value in ML for 5 hours (in seconds) should be 18000.
Hope that precision of 1 sec will be more than enough for your linearization.
Even 1 minute step will be good.
In this case linearization should work.
If not - use formula from Help.
Yes, I don't need the precision of ms but, that's the way the time works, if set a timer of 5hrs y got an MLof 1,800,000.
the point is using a time input directly stored on an ML, and handle a TIME input as a number that would be easy to handle, what you suggest is to use minutes as hours, seconds as minutes, and 10msec as 1 sec. that would work for having an input of "REAL TIME" to an ML but I could use the same timer counting down as an input.
My core logic is simple:
1. Have a TIME input on the screen
2. Load that TIMER on the ML
3. Start the TIMER
4. Get the output as a function of time.Again, that's the "easiest" way to handle a recipe with MANY time inputs, that way I use the screen variable timer as an input because I have 1 input per time value and I don't need to convert HR:MM: SS and count, since a single LD does that conversion and just need to start the timer.
As mentioned above I solve the problem by not using the LINEAR function and using the math of linearization on a formula, I am not asking for a solution. I already solved it and the software has been running without problems.
Maybe I am using this in a way that was not thought before (I get that using a timer to count down and that as an input on a linearization is not a usual thing) In my opinion that was a very creative solution to a very specific problem that I needed to solve.
The issue here is that this conditions on the LINEAR function:
X2=0 (End value as the timer goes to 0)
X1=1800000 (timer value 5:00:00:00 loaded on ML)
Y2 = 6000
Y1=600should work for every value from 180000 to 0, because every value is within the ranges that the help file listed, I read that before even try.... and to be honest the solution worked until the right conditions meet and then it did not.
-
11 hours ago, Ausman said:
Pls upload the program you've done for the example above so that others can run it and check. I can't as I don't use 700s.
Reading the above makes me think that you don't know a crucial thing that linearisation needs to work properly. It does NOT stop at the Max and Min values you specify. If your program is going to possibly give readings that will overshoot you have to have Max and Min compares going on that store the max or min value if an overshoot has happened. This is done directly after the linearisation in the ladder.
This is a confusing thing for first time linearisation users. Pls read this entire topic:
As far as I know this hasn't been done yet. One for @Cara Bereck Levy to ask? .....Again. I've always said I don't think it could be too hard, but I do know that the Vision system has limited "space" for mods.
cheers, Aus
🤦♂️ @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
Y1=600
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. -
Me again, I tested those 3 options:
- The red one is using the time loaded on an ML and then the LINEAR function as mentioned before.
- The green one is obtained by loading the initial ML value of 5 hrs (1800000) at the beginning, and then subtracting on each SB 13 (They don't match because I tweaked it to do it at a different rate than the real-time ) using the LINEAR function.
- The Yellow one is the mathematic formula that does the same as the linear function using time loaded on ML in real-time as an input.
So based on this evidence, seems to be an issue with the LINEAR function as I suggested before, not with the Time or the ML used to store the variable being used on another vector (There is nothing else running in the background of this program)
-
On 6/11/2021 at 2:36 PM, Flex727 said:
In my opinion, no. It's a good opportunity to explain that a PLC is always the best simulator and is usually cheaper than software simulators for other manufacturers.
well I think that we should compare with similar manufacturers, taking that into consideration codesys is free and I have a virtual PLC with all the capabilities and even servo motors...
Sometimes is not always possible to have the hardware or the machine available and you need to simulate and test parts of your code.
For example, one time I simulated a complete machine on codesys, I used a virtual axis with specific motion profiles to simulate the actuators and even was able to see the movement and test the logic of my program. indeed I did 2 virtual PLCs running at the same time one was the logic of the machine and the other one was the "machine" itself that responded to the first virtual PLC.
And I was able to set up a machine right in my living room without having any physical device connected. -
20 hours ago, kratmel said:
Hi,
maybe i know what is wrong.
Your application works in real time. Then sometimes linearization maybe do not end at the time when ML must be reloaded.
In ladder code you send timer to ML and after that do linearization.
Please try to change ladder net - first linearization - then copy timer to ML.
P.S. This problem appear only in this two times at every working cycle or bug happend in different time point at every new cycle?
I already did the change and same thing happen but kind of different, instead of a step looks like a spike but still overflows above 7000 while the maximun value in the LINEAR function is 6000
I am going to test with a counter and let you know if the same happens
-
The problem is not the ML being part of another vector, the program that I uploaded was done in a new project, I extracted the part of the code that was having problems to a subroutine, (That why is being called as a part of the main routine on START RUN), ignore the Sets since this is not the full program I just did not bother adding the Resets. the uploaded program was only for test and was intended to be downloaded into a PLC and start once, I just wanted to test the issue without anything else in the PLC.
I know that Rung 1 on Step.run looks weird but if you look closely MB1988 is the same contact just NO and NC on each branch so is technically correct for the software... I mean MB1988 can not be Open and Closed at the same time... just the same as doing this at some point :
Why do I use timers instead of counters and ticks... well this is a good point and the main reason is kind of complicated to explain, but In my defense, I am not doing anything that isn't supposed to be done. Long story short I need to load recipes with many times that could be as many Hrs, minutes, and seconds as the user wants and many many steps, ok so the easiest way to handle that is to have a time input on the screen and then load the time into ML that way I have a number that can be counted and easy to handle in the recipe and changed at any point, I mean I guess I could have the input for HH MM SS and then convert to a number and count but it's having more steps than load the timer value on a ML, since the ML is updated ever time the time changes I don't need to count anything so...
In short, the weirdness of the program is de a "copy and paste" and some things deleted but the logic is not complex at all, and I am following all the indications in the manual, any way you had a good point if this is a LINEAR function problem I should have the same behavior using number counting instead of time conversion I will try that and test.
By the way, my logic is already solved and runs great, I decided not to use the linear function since the problem was there and do the math instead with the time loaded on the ML.
-
Hi all first, I want to say that although I really hated unitronics at the beginning I am quite impressed by the capabilities of the PLC+HMI all in one.
so, I am using the Linearization function as follows: I convert a timer into a numeric value and then ramp up or down some variable, in function of time, my values are X2,X1, Y2,Y1, X, Y...a simple linear function. let's have this example going from 6000 to 600 in a period of 5hrs, so the variables are as follow
X2=0 (End value as timer goes to 0)
X1=1800000 (timer value 5:00:00:00 loaded on ML)
Y2 = 6000
Y1=600
So far is a simple Linearization larger time value =minimun value, smaller time value = maximum number value the time is going down while the output is going up? So the linearization function "works" but at some specific time values boom! the output ..overflows?
The green line is the timer going down, about at a remaining time of 3:53:40 (1402000 in the ML) the output value of the LINEAR function suddenly increases by 2400 then goes back and then increases by 2400 again, this happened again at another time with another set of variables 3:00:44:13 (1084413 in the ML ) going from 3500 to 500
I know that the linear function has its limitations but even with these limitations I am working within the range :
"
Note ♦
The X and Y values must not exceed the range of -2147483648 to +2147483647.
Known Issue
Note that the Linearization function cannot be used in cases where one of the following is close to the value FFFFFFFF:
One of the inputs
An intermediate calculation"So in conclusion, I am doing something wrong, or is this some stupid bug?.... this particular issue was about to be catastrophic for my application
I added a test program that runs on V700 hardware to demmostrate the issue
What will be the best way to handle this data handling?
in Vision & Samba PLC + HMI Controllers & VisiLogic Software
Posted
Oh boy! it surely does, the ammount of small details im implementing for this is crazier each time... the end user will be requesting new changes until there is no more time to do changes