Salut guys,
I have a situation, that my macro stops, when a return-code of a "0" is returned. I did not tried with a lot of functions, in my special case it was only two lines on a symbol:
1. Program("load")
2. Set some variables.
So after a restart (program not loaded), the macro runs perfectly (program is loaded, so return code = 1, variables are set)
when running the macro right after the second time (program already loaded), macro does not work.
When manually unloading the program and run the macro again, it works.
The only explanation that I have, is that if the program is already loaded, the return-code is "0" from that line and the macro stops?
Do I have a logical error in my concept or do you think it is a bug?
Thank you in advance.
Salut,
Could you be more accurate please?
Macro SCADA Basic VBA
The best would be having a sample project with the described behavior. At least Varexp, Global file and the program.
BR
Edouard
Yes Johannes, I dont really understand as there is no relations between macro and scada basic program !!!
Hello,
I mean the default macro-animation in the HMI of PcVue. I have a symbol and onclick, a macro is proceed.
I will attach a screen.
First Screen shows the animation, which does not work (the program("load") is first line.
Second screen shows the solution, where I just put the "program("load")" into the last line. This works.
the first one not, if program is already loaded (variables cannot be set).
Configuration causing the problem:
Configuration solving the problem:
I would have 2 remarks:
1/ Using SENDLIST with mode BLOC could be dangerous, it would be better using mode MULTIPLE by default
2/ In my opinion, Run-Macro animation are not designed to be used that way. You cannot expect it to behave exactly as 5 lines in SCADA Basic.
I am afraid trouble can be met depending on OS, computer configuration and future versions of PcVue.
Edouard
Hello Eduard,
1. This variables are intern variables. The problem is, that "@varname = value" is not working with macro. In my case "BLOC" and "MULTIPLE" should be the same? if not please explain ;).
2. What do you mean with that? Could you explain that?
- why OS?
- computer configuration
- future versions?
This point is important for me, because I use the macro in a PcVue-integrated library, where I need SCADA-Basic for sorting loglists.
The help says definitely, a macro is used to avoid SCADA Basic and also all functions I use are supported (help):
- Program
- SET
- Sendlist
Johannes,
I dont know exactly what you are trying to do but I feel that you are taking the wrong way by using these macro animations.
Also, take care on the help. Firstly it can have some mistakes, secondly you can see a list of Instructions here that are supposed to be compatible but, maybe, not all modes. And if 1 particular mode is not supported it wont be written!
To complete what Edouard said, using the macro to make a generic library is risky as you will probably found some limits. And what will happen if you have more than 5 lines of instructions? Or you must do an instruction which is not possible by Macro? I suppose in theses cases you will use a scada basic program. Therefore why not doing all by scada basic (or VBA)?
The idea of the Macro animation is to execute a short script without creating a program but punctually. I mean you have 1 button somewhere doing 2 instructions and you dont want creating a specific script for that. But for a symbol from a library it makes sense doing a program as, usually for a Library you have a long set of scripts. May be a lot of small scripts but still a lot of. Then you document them as well with comments, versioning, etc...
That's my point of view of course...
Nico
Hello Johannes,
1/ I confirm that with internal variables, SENDLIST mode BLOC and mode MULTIPLE are the same.
2/ Unfortunately, in PcVue documentation, it is not written clearly what is mentionned in training modules:
---------
Call a Function from another program
You can call a Function which is in another Program using the built-in Instruction PROGRAM. But take care; the Function will only be called when the calling Function ends. We say it is an asynchronous call.
---------
That is the reason why this post exists.
and probably this one also: "SCADA Basic: works without GLOBAL program?"
And for that reason also, I imply the behavior could be slightly different depending on OS, computer, ...
Hello again,
1. sorry for my not understanding. I call a function(which is supported by macros, said in help) "program("preload",...)". The program is loaded or not. SCADA basic (or macro) does not care, does it? If it cannot be loaded, return-code "0" is returned, but the instruction ends (with zero). Why it should break my macro?
2. the reason for the macro is, that I am developing a PcVue built-in (in the product, like SH_Navigation)library. So SCADA Basic is not allowed, because the prerequesit is to load the special program of the library. For that you have to create a "init"-script and so on. We cannot provide such kind of library with PcVue. So my solution was to load the lib-program every time a symbol is clicked. if not loaded, it loads, if loaded, nothing happens. The SCADA Basic itselfs is called from the "before"-function of the mimic (in fact a Popup-mimic on the symbol). The SCADA Basic code inside is of course to complex for the macro, but in my case, I only load the SCADA-Basic program through the macro. also some intern navigation variables are set through the macro (I could do it as animation also) to reset the filters of the popup.
the problem is, that when I use load-program before the set-variable function, the set-variable function is not performed if program is already loaded.
So is that really the correct way of working?
is it really related to Eduards statement:
"Call a Function from another program
You can call a Function which is in another Program using the built-in Instruction PROGRAM. But take care; the Function will only be called when the calling Function ends. We say it is an asynchronous call. "
And could you please explain for non-developers, why the success of an asynchronous call is depending on OS, computer or anything else. I do not understand that.
Like I said I could solve the problem by putting the load Programm function into the last line.
Could it also be a problem, depending on whatever?
Thank you in advance.
PS: could be a good ITM Presentation 😉 😉 .
Hello,
I fully understand Johannes' concern, but I think it is not perceived well.
The core message is:
- When you do a PROGRAM("PRELOAD",...) in the first line of a macro and the program is not already loaded, then the rest of the macro (lines #2-#5) will be executed.
- When you do a PROGRAM("PRELOAD",...) in the first line of a macro and the program is already loaded, then the execution of the macro is interrupted.
Why is it like that?
For me this behavior appears strange at first glance. The implicite assumption from Johannes is that this is because the return code of the function in the second case is 0. It looks like it is the cause, but it could also be for different reason.
Please note:
- It is not a PROGRAM("START",...) or PROGRAM("EXECUTE",...), only the preload.
- If the issue was due to asynchronous execution it would not be as reproducible as it is in this case.
- The behavior is completely independent of what is the instruction in the subsequent lines of the macro.
So, finally, for me the goal is not to answer if the animation "Macro" has been designed for operations like these or not, it is rather to explain this strange behavior, to verify that the return code of a single line in a macro really has an impact on the rest of the animation and being able to document it if it is really true.
I agree too but I don't think any of us can answer these strange questions. I hope I am wrong.
You should better write a SPR in my opinion.
Hi Armin/Johannes,
I understand but, as said by Ludo, I guess nobody has this answer. It looks like a SPR.
Now you must understand our answers. When a customer reports to us a problem we always try understanding the need and if we understand it we try finding a work around. This is exactly what we did here.
Nico





