Sign in to follow this  
Followers 0
TheFox

ProcessYN

14 posts in this topic

Hi all, A customer of the company I work for in Ontario, Canada purchased some equipment a long time ago. It came with an HMI screen created with ProcessYN 3.50 (PCS 3.50). They are looking to update this HMI to Wonderware so my company is trying to use the ProcessYN 3.50 softwrae they have to determine the addressing of objects used on screen. This is very old software (DOS based) and to make things worse it seems to be in Italian and not straight forward. I was wondering if anyone has seen this software before and would have some useful links, tutorials, or a manual they could share? I appreciate any insight into this software.

Share this post


Link to post
Share on other sites
Processyn is not an italian software, it's french. Processyn was develloped by Logique industrie compagny but i'm not sure they still provide support on the DOS version of this software cause it's really old. JC

Share this post


Link to post
Share on other sites
Yeah I know it is french, from France. I also know the company that makes it and have found their webiste. I even tried to contact them but the e-mail address they provide bounces back. As well, it may be french software but the comments in the development are all Italian. Thanks for the information though.

Share this post


Link to post
Share on other sites
If you can read the comments that means you have the text source file (.src) or the binary source file (.pcs). Is it correct ? if so you have all the code inside it including the animation links. With Processyn DOS you had to build the graphic screen with a dedicated tool first and then the animation was done by code in the @GRAPH descriptor. You had to specify the position of the object on the screen that you need to animate. It's a little bit difficult to explain it in english but it's easier with the software. The problem is you need a devellopment dongle to do it. If you just have a runtime dongle you will have to deal with the text source file but its more difficult. JC Edited by acpi

Share this post


Link to post
Share on other sites
I have the SRC file. It is broken into a few sections. SYNOPTIC, CRONO, MEM, FILE, A_B, CAMPIO, ANIMA, ELENCO, CODICE, and SIST. I am having trouble making the connection between the displays I can see in the graphical editor and how they are linked to I/O. I have attached a screen shot of PCS running in DOS so you can see the menu items available as well as the SRC file (renamed to .TXT because I am not allowed to upload .SRC). For an example frm the SRC file instance: On one of the screens I have 2 text boxes, one says MAN and the other AUTO. There visibility is affected by whether the machine is in Manual or Automatic. Shown in the SYNOPTIC section they appear as: TEXT 2 0 3446 1014 154 "MAN" TEXT 2 0 3753 1014 154 "AUTO" Then in the ANIMA section I believe that the lines of code are: B15_7 6 COL 2 0 3548 1065 (this is the address of the MAN bit in the PLC, the actual PLC address is B15:7/5 but the PLC is 0-15 and they mapped the HMI 1-16) B15_7 7 COL 2 0 3900 1052 (this is the address of the AUTO bit in the PLC, the actual PLC address is B15:7/6 but the PLC is 0-15 and they mapped the HMI 1-16) Now where I get lost is where in those 2 line is the command that tells it to change visibility? As well on the same screen I have horizontal bars that fill based on speed of a motor. I think the section in the SRC file describing them is: SCEGLI COL 4 0 3746 2972 ANIM ANA A6 DESTRA 3 0 0. 350. 489 2518 1801 2441 A7 DESTRA 14 0 0. 2045. 489 2562 1801 2441 A9 DESTRA 3 0 0. 310. 489 2319 1801 2242 A10 DESTRA 14 0 0. 310. 489 2364 1801 2242 A12 DESTRA 3 0 0. 1200. 489 2121 1801 2044 A15 DESTRA 3 0 0. 90. 489 1922 1801 1846 A18 DESTRA 3 0 0. 90. 489 1724 1801 1647 A19 DESTRA 14 0 0. 100. 489 1769 1801 1647 A22 ALTO 14 0 0. 23. 175 1186 482 98 A23 ALTO 3 0 0. 25. 278 1186 482 98 A25 ALTO 14 0 0. 145. 668 1186 975 98 A26 ALTO 15 0 0. 145. 668 1186 770 98 A27 ALTO 3 0 0. 145. 770 1186 975 98 A29 ALTO 14 0 0. 23. 1212 1186 1519 98 A30 ALTO 3 0 0. 25. 1314 1186 1519 98 A32 ALTO 14 0 0. 145. 1711 1186 2018 98 A33 ALTO 15 0 0. 145. 1711 1186 1814 98 A34 ALTO 3 0 0. 145. 1814 1186 2018 98 But once again I need to be able to decipher this code. Thanks again for your help. app_screen.bmp NG310.TXT

Share this post


Link to post
Share on other sites
Hi, You're a lucky man cause the source file was just a saving option and there's a lot of programmers that did not use that option. In addition you have the original pcs file too so it's really cool. Usually the italians don't give all the sources to their customers. Well i'm going to try to explain how it works. I think it will be easy for you cause you have inderstood the basics of Processyn. The SYNOPTIC descriptor is automatically generated by the software when you export the source file. The screens was made by the graphic editor called "editore grafico" in your screen capture. Eventually the animation is made in the ANIMA descriptor. In your example : B15_7 6 COL 2 0 3548 1065, the last two figures are the X/Y coordonates of the animation on the page 1 (PAGINA 1). Col means color and 2 and 0 are most probably the color codes for 0/1 value of the tag. I can't remember what colors it could be but its' not important. B15_7 6 is a digital tag declared in the MEM (memory) descriptor, it's the 6'th element of the B15_7 digital array (B15_6 16 L). The link with the external tag must be done is the CODICE (code) descriptor. I don't have time to analyse that part but it must be a 16 bits word declared in the A_B descriptor wich is converted in 16 differents bits for animation. By the way the A_B descriptor is the place where the plc tags are declared. If you want to see on the screen where the animations are located you just have to enter the text editor, it must be editore testo in your screen capture. Then you go to the animation descriptor. It's classified by screen (pagina = page or screen) then it's classified by animation types. In our example it's a digital animation (ANIM DIG). You delete the last 2 figures (3048 1065) and you should be automatically redirected on the pagina 1 (page 1) with a cross over the graphics. So you're able to see where your animation is located. Once again it's hard to explain (even in french, so imagine in english ) but if you can do it one time then it's really easy. This is the same story for the other types of animations. ANIM ANA means analogic animation, ANIM MESS means message animation and so on. Each time the last figures are the X/Y location onto the screens, the other figures depends of the animation types. I could retrieve my manual to explain it in details but i have to come back to my office and it won't be before a week. If you have a runtime dongle on your computer and not a devellopement dongle, don't try to generate the application (generazione) otherway the generated file won't work with the runtime dongle. If you need more informations you're welcome. JC Edited by acpi

Share this post


Link to post
Share on other sites
Thanks for your help. It is very much appreciated!!!

Share this post


Link to post
Share on other sites
If there is any way of getting a copy of the manual that would be really helpful. We are still having difficulty trying to figure out the analog animations. It seems that the analog values are all being scaled with this code / software at the terminal and we need to make sure that we figure out all of the proper scaling in order to convert it properly. Also, we are having difficulty with one recipe screen trying to figure out how the input fields on the screen are tied to a specific address in the PLC. The fields (C4, C5, C15 etc.) don't seem to reference any valid PLC addresses. anyway, thanks again for your help. Chris.

Share this post


Link to post
Share on other sites
Hi, The problem with my manual is that it's a paper version not an electronic one :( I could scan it but I'm no sure it could help you so much cause it's in french... Concerning you recipe screen here are some tips. C4 and C5 are not directly linked to the plc. These variables are logic inputs. They're used in the code to manage the recipe. This recipe is in fact a file. This file is declared in the FILE descriptor (yes this time it's the same word in English :) ). It's composed of a message type variable (C1F witch is probably the recipe name) and some integer type variables (C12F to C47F and D2F to D12F). To manage a file in the CODE descriptor you have some pointers. “LEGGI” is the read pointer, “SCRIVI” is the write pointer. In the code you find several lines to control the recipe. It starts at “******** GESTIONE DELLE RICETTE (management of the recipe). I don't know exactly how they write the variables of the recipe to the plc but it seems they use a loop to write N9_144 witch is plc buffer variable that can be found in the A_B descriptor. So we can imagine that you have some code as well on the plc side to manage this function. The syntax of the Processyn code is in the language of the user. That's why it could disturb an English spoken person but in reality it's very close to BASIC or PASCAL language. SE means IF, ALLORA means THEN and FINE_SE means ENDIF. So let's take an example with your C4 variable, in the code you can find these lines : SE CURSORE_SU C4 ALLORA C3 R H SE_NO C3 R L FINE_SE you can translate it by : If cursor is on C4 then C3 Receive High (1 value) Else C3 Receive Low (0 value) End if Basically, if the cursor is on C4, C3 is set to 1 else C3 is set to 0. It seems C3 is used to cancel a recipe but i'm not sure as i don't have the full application and it's much more harder to decipher the code with the text source file only. I hope it will help you a little to move forward. JC Edited by acpi

Share this post


Link to post
Share on other sites
Hi JC, I have one more question that I was wondering if you were able to help us out again. Here is an example of an IF statement that I would appreciate clarification on. -> SE ( N9_4.5 PV H ) ALLORA I think this simply means --> IF N9:4/5 IS HIGH THEN I'm specifically looking for clarification on what PV does. Is this just a built in evaluator to be able to check if a bit is H or L? Is there a reason why they would use that method instead what is otherwise used, simply --> SE N9_4 [ 5 ] ALLORA They also do use --> SE N9_4 [ 5 ] PV H ALLORA Additionally, BIN_ANA isn't declared anywhere that I can find. I'm sure it is just a built-in mechanism to interact with individual bits in a word in the PLC. It appears to bitwise AND (E) and OR (O) two words together. If you could confirm that it just a bitwise manipulator then I can get that off the list as well. Hopefully that's it! Thank you again for all your help. Matt

Share this post


Link to post
Share on other sites
Hi, The PV test function is a little bit more subtle than that :) Processyn is one of the only SCADA system i know witch is able to test so easily the rising or falling edge of a variable more or less like a PLC. PV means "Prendre la Valeur", in English : "take the value", and it's naturally associated to H (High or 1) or L (Low or 0). In your example when N9_4.5 value change from 0 to 1 and eventually 1 to 0 they use a mask to write the tag (N9_4) that is sent to the PLC. You're absolutely correct about the mechanism of the mask which is based on a logical AND and logical OR between two words. However, pay attention about N9_4.5 and N9_4 [5]. It's not the same thing, the first one is a boolean variable declared in the MEM descriptor and it's used as a buffer variable to write N9_4 (N9_4 [0] in fact) while the second is the fifth word of the N9_4 words array declared in the AB descriptor which contains the tags exchanged with the PLC. JC Edited by acpi

Share this post


Link to post
Share on other sites
Hi JC, Merry Christmas et Joyeux Noël. Thank you very much for that explanation. For example in context, the PV function would be used to detect a momentary push-button input on the PLC. Or as another example for a PV H, Was Low, Went High, Is Low. We have found something else that we don't yet fully understand. In the AB descriptor, some tags are declared as follows: USC ANA N9_138 138 0 N9_140 140 0 N9_142 142 0 N9_144 144 0 N9_232 232 0 N9_234 234 0 That's fine. The number following the initial N9_### is the exact same. No need to worry. And these are all under the USC ANA. We assumed the 0 was initializing the tag with a value of 0. However, under ING ANA things are declared differently. They all have valid PLC addresses first, then some value, then a variable declared in the MEM descriptor (REF_X, REF_E, REF_5) which are all themselves initialized as Low, followed by a 0. Our concern is that we don't know what the second value actually is. We don't know why the second value is always an even number. We don't know why REF_X is being used either. If L is 0, and REF_X is L, why are REF_X and 0 being used? However our most pressing concern is that highlighted below, N9_189 does not exist in our PLC application. But N9_190 does. Nowhere within the application is N9_190 ever referenced. Likewise, N9_189 is used nowhere within the PLC. This realization originally led us to believe that the second value was the mapped tag within the PLC. However, looking at the final N9_227 with the second value being 262, we quickly realized that this could not be the case. We simply cannot figure out how N9_189 only exists in code, N9_190 only exists in the PLC, and the only apparent link is N9_189 190 REF_E 0. Any clarification on this matter would be extremely grateful! ING ANA N9_146 146 REF_X 0 N9_147 148 REF_X 0 N9_148 150 REF_X 0 N9_149 152 REF_X 0 N9_150 154 REF_X 0 ... N9_188 188 REF_E 0 N9_189 190 REF_E 0 ... N9_224 256 REF_5 0 N9_225 258 REF_5 0 N9_226 260 REF_5 0 N9_227 262 REF_5 0 Thanks in advance! Joyeux Noël et une heureuse nouvelle année Matt

Share this post


Link to post
Share on other sites
Hi Matt and happy new year to you as well, Sorry for the late answer but it was vacations for me and then I've been very busy at work. About your questions I'd like you send me the source file of your application cause it's easier for me to browse a text file with a text editor instead of searching on paper as i did until now. Give me a pm and i'll give you an email adress to send it or if you prefer you could upload it on a files share server like rapidshare. Thanx. JC

Share this post


Link to post
Share on other sites
Hi, Once again i'm sorry for the late answer but i'm really busy these days. Here are some answers. You must understand that N9_189 or N9_227 are just names, you could call it Variable1 and Variable2 its not important. What is important is the second value wich is the real adress in the PLC. By example N9_189 has the adress 190 ans it means you read N9_190 in the plc. You see the picture ? Of course the original programmer wasn't very smart by naming N9_227 a variable that is in reality N9_262 in the plc or N9_189 for N9_190. I don't know why, maybe he wanted to fake the ennemy and now you're the "ennemy" JC Edited by acpi

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0