Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: Logic Server not sending triggered events
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Trying to work out what I did wrong but as far as I can tell nothing.

I have the logic server setup with run timers - field on, logic server starts a timer field - that all works fine.

Setup a triggered event for the field - >= a set time it is supposed to send a trigger but nothing is showing up in the Event Triggers window.

Did a sanity check and created a follower boolean field.  Turn on a boolean field in a different driver (and set a triggered event on it as well) and the logic server just follows that drivers state.  Added a trigger on the logic server field identical to the field it is following.

Turn on the bool and the event is registered, the logic server turns on but no event for the logic server is recorded.

So at the moment for me, all events from the logic server driver are not triggering events.

Is it broken or did something change.
For fields that you put a trigger on yourself, the logic server doesn't get involved. That's done at the base driver level and it wouldn't know if it's a logic server driver or not. So on that one, it would seem like it has to be your trigger configuration is off. What value are you putting into the comparison field for the trigger?

BTW, you would definitely want to set such a trigger to be latching. Otherwise, once you get it working, it's going to send a trigger every time the field changes and is above that value, which will be very bad.
The field in the logic server has a trigger on it "Is True" - very simple. The trigger was also put on the field driving the logic server field to prove that the trigger system was working - same trigger - "Is True"

Only one trigger is coming through - nothing from the logic server

For a bool, latching makes no difference, unless the system send a trigger every time it scans etc.
Wait, the expression you put on the field in the actual configuration of it in the logic server has nothing to do with triggers. It just sets the value of the field based on the values of the incoming source field values. Maybe I'm misunderstanding you but it sounds like you are talking about the expression in the logic server configuration for the field and the expression you use when you add a trigger to a field? The former has nothing to do with triggers, only the latter.
Everything you said is true and has nothing to do with the problem. The logic serer is not sending triggers to the event system.....

OK - to keep it simple.

There is a field in the logic server that is a bool. There are two bool fields assigned to it and any true. Expression type is true. That means when either of the fields are on the logic server field is on.

Simple so far.

When the logic server field transitions to True I want a trigger so I can run a triggered event.

In the driver config for the logic server I set it "send a trigger on any value change"

I then set one of the fields to true, the logic server field goes to true and no event is recorded by the event system.

To check if the event system is working (sanity check), I put the same trigger on one of the fields that is used by the logic server field.

Again set the field to true, the logic server field transitions to true, the event system records the event for the driver field (one of the fields used by the logic server) but nothing from teh logic server - the logic server is not sending anything triggers to the event system.

Not sue how much simpler I can explain it.
OK, that's clearer. It wasn't totally obvious from before that that was what was going on. The gotcha here is that that configured trigger stuff is handled generically at the base driver class. So I don't think it can have anything really to do with logic server vs. not logic server, since that code wouldn't know or care what the derived driver class is. The triggers are actually handled even below the base driver class, it's done in the class that stores the field values. So if the field value changes, it should happen. There would seem to need to be some other explanation for it that we need to explore.

Are there multiple computers involved here? If so, are the two drivers on separate machines? That's the most likely answer that comes to me just from what we know so far. Triggers are UDP broadcasts so there are things that can interfere with those. But, OTOH, the logic server runs on the MS and most likely you installed the driver there as well, is that the case? If so, were you watching for triggers locally there on the MS? Or, if there are two machines involved, were you watching the trigger monitor on the same machine as where the driver is installed?

It can't be that the incoming trigger port is blocked or you wouldn't see the other event.

Just as a sanity check, can you create a numeric logic server field? Maybe one that sums the value of two dimmers or something and sends a trigger when non-zero maybe. Then set the dimmers such that the sum should be non-zero. Let's make sure it's not something specific to boolean fields and is consistently just that one driver or not.
Its not contained to bool fields because I started this from an elapsed time field that would not trigger. The bool fields were just for testing.

Out of desperation I restarted the CQC services and it appears to be working now.

What I don't understand is why only the logic server stopped sending events but every other driver was. That is what caught me out and why I didn't do a restart earlier (restarting screws up a few calculations so I dont like restarting).

As of this morning after the restart the event subsystem was receiving event from the logic server.
I dunno. As I said, the code that does that stuff wouldn't know or care what driver it is, it's all very generic stuff.

If you go back to the elapsed time, be sure it's latching, else it's going to blast out triggers forever once it crosses the threshold. It's possible that did some sort of damage before when you did that I guess. It shouldn't have but I guess it's one of the more reasonable scenarios as to why just that driver. I'll put it on the list to look at.