I'm reading the documentation article called Conditions. In that article it describes:
You can carry out conditional logic in scenes using values from the session.params, user.params, intent.params and scene.slots.params objects.
What I can't seem to find is any documentation on intent.params and scene.slots.params. I am guessing what these mean but this article seems to be the only reference to them.
I had assumed that scene.slots.params would be the names/values for scene oriented slots.
And now the question ...
If I have filled a scene slot and wish to echo that back to the end user, can I use $scene.slots.params.[NAME] in my Prompt value?
Reading the documentation on Storage: Session and Storage: User it seems that these are the only two storage areas that can be used in outgoing prompts.
Related
Roald has written an excellent guide for the Twincat Eventlogger.
https://roald87.github.io/twincat/2020/11/03/twincat-eventlogger-plc-part.html
https://roald87.github.io/twincat/2021/01/20/twincat-eventlogger-hmi-part.html
For us this is exactly what we want, there is however 1 thing I haven't figured out. How to get the sourcename of the alarm in multiple languages in the HMI. params::sourceName gives the path in the software (example: MAIN.fbConveyor1.Cylinder1) This path can be customized when initializing the alarm (as Roald has shown). This doesn't work in my case, since I would like to define a generic alarm (example: "Cilinder not retracted within maximum time") that is instantiated multiple times.
I was thinking of using the source as a way to show the operator where the alarm occurs. We use this way (path) already for saving machine settings among other things. The machines we build are installed all over the world, so multilanguage is a must.
Beckhoff does support multilanguage alarm names (when defined), but the source is not defined, but dynamically generated.
Anyone have an idea how this problem can be solved?
If I understand your question correctly, then being able to parameterize the event text with information of the source of the problem should help you out.
If you define the event text as Cylinder {0} has not retracted in time. then you can add the arguments of that text during runtime.
IF bRaiseAlarm THEN
bRaiseAlarm := FALSE;
fbAlarm.ipArguments.Clear().AddString('Alice');
fbAlarm.Raise(0);
END_IF
However, since this also stated in the articles you mentioned, I am unsure if this would solve your problem.
'Alice' in this example, can be hard to localize. The following options come to my mind.
The string can be based on an ENUM. Enums can have textlist support, so if you add your translations there, that should allow multilingual output. However... this does require a lot of setup, placing translations inside your code, and making sure the PLC application is aware of the language that the parameter should use.
Use tags to mark the source device, as tags can be language invariant. It is not the most user-friendly method, but it could work for you. It would become something like: "Cylinder 'AA.1123' did not retract in time.". 'AA.1123' as a tag would have to be stored inside your PLC code as a string. You will have to trust that your operator can relate the tag back to the actual source.
Hopefully, this helped, or else please help me understand the problem better.
I'm looking at the documentation, but I find nowhere an information for setting a global variable. We know that the Cloud functions are stateless code snippets, but I want somehow to integrate a global variable which can be changed by an action, read by another one and remain with the last state (true/false).
Is there any way for achieving such functionality?
Function invocations are stateless, so that means there are no global variables. As stated in the comments, you could utilize a database to store state information.
Since you only want to avoid calling an API too often and not have a database, the only other option I see is to modify the action parameters. Utilizing the Cloud Functions API you could update the action itself and switch a parameter from false to true. I would not recommend it.
I am gathering some context variables with slots, and they work just fine.
So I decided to do in another node of the conversation, check if one of these context variables is a specific number:
I was thinking on enabling multi-responses and check if, for example $dni:1 (it is an integer, pattern of 1 integer only), or if it is 2 or 3:
But this is not working. I was trying to solve it for some days with different approaches but I really cannot find a way through it.
My guess is that a context variable has a value, and you can print it to use it like responding with the user's name and stuff like that (which indeed is useful!), but comparing values is not possible.
Any insights on this I can receive?
Watson Assistant uses a short-hand syntax but also supports the more complex expressions. What you could do is to edit the condition in the JSON editor. There, for the condition, use a function like matches() on the value of the context variable.
Note that it is not recommended to check for context variables in the slot conditions. You can use multi-responses. An alternative way is to put the check into the response itself. There, you can use predicates to generate the answer.
<? context.dni==1 ? 'Very well' : 'Your number is not 1' ?>
You can nest the evaluation to have three different answers. Another way is to build an array of responses and use dni as key.
Instead of matching to specific integers, you could consider using the Numbers system entity. Watson Assistant supports several languages. As a benefit, users could answer "the first one", "the 2nd option", etc., and the bot still would understand and your logic could still route to the correct answer.
Unreal Engine 4 provides three specifiers to control the visibility and editability of an C++ class member exposed to Blueprint via UPROPERTY().
The documentation in the UE4 source code (see also UE4 wiki, UE4 documentation) says the following regarding editability:
For VisibleAnywhere, VisibleInstanceOnly, VisibleDefaultsOnly:
... cannot be edited at all.
For EditAnywhere, EditInstanceOnly, EditDefaultsOnly:
... can be edited ...
For BlueprintReadOnly:
... can be read by blueprints, but not modified.
and BlueprintReadWrite:
... can be read or written from a blueprint.
Questions:
Since the Visible* specifiers already restrict the usage to read only in Blueprints, why it is used in conjunction with BlueprintReadOnly? Isn't the second specifier superfluous? Example:
UPROPERTY(VisibleDefaultsOnly, BlueprintReadOnly)
UMyActorComponent* MyActorComponent;
Even more confusing is the usage of Edit* specifiers, which allow read and write in Blueprint, together with BlueprintReadOnly which restricts to read only in Blueprint. Aren't both specifiers opposing each other? Example:
UPROPERTY(EditAnywhere, BlueprintReadOnly)
UMyActorComponent* MyActorComponent;
Are the Visible*/Edit* specifiers valid in a different context than the BlueprintRead* specifiers? (the question is not about InstanceOnly (property windows for instances), DefaultsOnly (property windows for archetypes) and Anywhere (instances & archetypes))
tl;dr
Visible*/Edit* specifiers allow you (typically a game designer) to access/modify a variable directly in Blueprint Editor for quick configurations of class properties.
BlueprintRead* allow you to get/set the value of a variable in the Event Graph when you're doing Visual Scripting.
Explanation:
Some namings and explanations in the official documentation are indeed a little ambiguous, especially for beginners. In a nutshell, both Visible*/Edit* and BlueprintRead* expose a variable in a class to the Unreal Engine, but do different things. In fact, both question 2 and 3 can be answered via question 1. Let's see your question 1:
Since the Visible* specifiers already restrict the usage to read only in Blueprints, why it is used in conjunction with BlueprintReadOnly? Isn't the second specifier superfluous? Example:
UPROPERTY(VisibleDefaultsOnly, BlueprintReadOnly)
UMyActorComponent* MyActorComponent;
Here you're exposing an ActorComponent to the Engine. Here I'll explain a non-Component member variable first, because specifiers for Component "appears" to work differently from non-Component variables.
Suppose I have a TpsCharacter class for a Third Person Shooter character, which has the following 3 float variables:
// The zooming speed
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Camera Zoom")
float ZoomSpeed;
// The FOV after zoom in
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Camera Zoom")
float ZoomInFov;
// The default FOV
UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Camera Zoom")
float DefaultFov;
They're all specified as EditDefaultsOnly, which means that, after we create a Blueprint class called TpsCharacter_BP based on this C++ class and open this Blueprint, the values of these 3 variables are editable in the Details Panel for this Blueprint class, as shown in the picture:
Of course, by using Visible* specifiers, they are read-only (greyed out in the Details Panel) so you can't change their values.
Now let's get back to your MyActorComponent. Like I said, specifiers for Component works somewhat differently.
Component appear in the Components Panel together with its owner class in the Blueprint Editor instead of in Details Panel like a non-Component variable.
When you have neither Visible* nor Edit* specifiers for a Component, this Component itself will always appear in the Editor, but you can't access properties/variables inside this Component., and Details Panel for this Component will be empty.
Visible* specifier allows you to access the Component's properties via its Details Panel, just like accessing the 3 variables in my TpsCharacter_BP class. However, when you declare it as Edit*, the Details Panel will show wired settings, allowing you to modify the Pointer value of this Component rather than its contents. This is definitely one thing you should always avoid.
Rule of thumb for Component: NEVER declare them as Edit* because it allows you change the pointer value to point to other things; always do Visible*. For a non-Component object you're free to set Edit*.
Now it's much easier to understand BlueprintRead* specifier. Is it superfluous with the presence of Visible*? Is BlueprintReadOnly opposing Edit* specifiers? Absolutely no. Are they valid in different context? Yes. The BlueprintRead* specifier allows you to read/write a variable in the Event Graph in the Blueprint Editor, that is, when you're doing Blueprint Visual Scripting. For my TpsCharacter class above, since all 3 variables are declared BlueprintReadOnly, I can get their values inside the Event Graph as shown here:
You can do the same for your MyActorComponent. By using BlueprintReadWrite, you can also set the value for these variables in Event Graph.
I write such long answer to explain because they can really confuse beginners though they're actually simple concepts.
I use (current-window-configuration) to save the size, layout etc of windows, and (set-window-configuration ...) to restore them, so that I can toggle between several window setups. However (current-window-configuration) also saves the current point in buffers, and I would like to only save the window sizes and which buffers they hold. I have tried two different ways to make this happen:
According to the function help of current-window-configuration, the variable window-persistent-parameters controls whats get saved. So now I only need a list of the available window-parameters. But when I look at this variable it's value is ((clone-of . t)), and I can't find a list of the available window parameters online.
I also tried looking at the object returned by current-window-configuration. It is a window configuration object, and gets printed as #<window-configuration>. Is there a way to get into this object, see whats inside and change stuff?
The parameters for window-persistent-parameters may be found in this manual page, though it does not seem to help with your question. A different set of parameters may be found by running (window-state-get nil).
The functions that deal with objects returned by (current-window-configuration) are listed here, but it also mentions:
Other primitives to look inside of window configurations would make sense, but are not implemented because we did not need them. See the file winner.el for some more operations on windows configurations.
At any rate, all these look like really low level stuff, so you might be better off just using winner.el rather than a custom made solution.