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.

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

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.

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

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.

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

Thanks for your help. It is very much appreciated!!!

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.

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

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

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

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

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

Hi,

Once again i'm sorry for the late answer but i'm really busy these days. Here are some answers.



It's correct indeed.



I have no idea why the figures are even. It must depend of the plc type but as I never used AB plc with Processyn I can't be affirmative.

REF_X is the variable used to refresh the values associated. It is written in the CODICE section (REF_X R CLOCK_V). CLOCK_V is a kind of pulse, V must means veloce (fast in english) by opposition to CLOCK_L witch means lento (slow). The value of the pulse is 60*0.01 sec = 0,6 sec. So your "fast" variables are refreshed every 0.6 sec and the "slow" every 1.5 sec. All the read only variables must have a refresh variable as the write variables are treated when the value is changing.

In the code section you can find :

COMANDO LETTURA DA PLC
SE INI_AB ALLORA
REF_C R H
REF_5 R REF_E
REF_X R CLOCK_V
REF_E R CLOCK_L

It means "Read command in the plc" and the refresh variables are written either with H (High=1) or with a pulse variables as i explained before.



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