Difficulty casting one variable to two separate blueprints from level blueprint

Hi - I have an external sensor reading and I want to pass it into two different character blueprints.
The characters can be toggled between as the main characters (ie a walker or a cyclist).
I’m not able to cast two global variables at the same time. It only casts the first “cast to” after “read serial”…which ever “cast to” node that comes after that is ignored.
Can anyone tell me how to fix this issue ?

Your player pawn cannot be both “runCharacter” and “wheeled vehicle at once” one of them will always fail.

So connect second half of this chain to fail instead of success from cast. But that may be confusing in few weeks when you read code.
Great help for such cases is sequence node.

Put RunCharacter cast (and its nodes) in one branch, and “wheeledVehice” and its nodes in second branch.

But remember both branches will never fire up together. I also suspect that you have troubles with references and pointers elsewhere (but its not on this graph).

Edit.
add print nodes to fail connection, see which one fails.

Thanks Nawrot - the sequence node works perfect.
Out of curiosity is there a more efficient way of ‘defining’ a real time incoming variable so that it can be accessed throughout one level.
As it stands I have two pawns using two different widgets being cast two different global heart rate variables…is there a way that the dynamic variable could be passed directly into a UMG text box and this one widget could be used by both characters ?
I suppose what I’m trying to ask is - can a ‘global’ UMG Widget be created ?

Depends where you have that variable in. I am just guessing now how your setup works.

first way is to use dispatchers:
create dispatcher in same blueprint that you have this event tick.
In dispatcher pass over that “return” value from read serial, or “introBPM”. (it will work just like function).
Call that dispatcher function instead of all those casts, calling it will send that value to every “listening” blueprint.

In those blueprints that need to “listen” to dispatcher:
on begin play event create cast to blueprint (that has dispatcher), then drag cast node and right click, then and create “assign to <your dispatcher name>”
it will create event and node setup for it.

Created event will always fire when you call that dispatcher in source blueprint. And it will pass over valuse just like function would.

Second way is using blueprint interfaces. It is bit more complicated, and confusing because you may end with same function in different blueprints (same name but not necessary same graph inside).

create blueprint interface, make function (make sure it has output “return” value, else you will get event instead of function)
Add that interface to your “destination” blueprint. Now inside that function in blueprint do whatever you want to do with values.
In source blueprint get reference to destination blueprint then either cast to INTERFACE, or do interface message.
It simplifies all that casting to different types, but for your case better is dispatcher.

Also watch tutorials about blueprint communication, this is something everybody must know, else you get more of such problems.

IMO and if I understood correctly, if you want to set a variable that will be displayed in the widget, then consider that each player creates their own widget that could already contain this “heartbeat” variable. All you need is a reference to that created widget and set the variable inside it. That way
Also I believe a “Game Instance” could be a good place to store player related variables since each player will create their own “Game Instance” at the beginning of the game.
Basically you can get a reference to the widget created, cast it to that class and get the textblock and SetText(Text) which ever you like.
I hope I was not too confusing.

Thanks - I definitely need to spend a few hours looking at blueprint communication tutorials as up until now I’ve controlled everything inside the level blueprint.
I think dispatches is what I will try first.