开云体育

I should probably stick with one problem at a time, but I decided to tackle another one toinight.

?

I want to setup my turnouts so that if the block they are in is occupied that the turnout that cannot be thrown. Is Logix the best way to do this? Logix is how I am trying to do it.

?

I think I have the action set correctly, but I am having an issue with the trigger.? My thought was to use the block occupancy to set whether the turnout is locked or not. But I have created a block and it is not showing up in Logix.? I could use the sensor that is determining block occupancy, but I am curious if this is the correct way to do this? I would think block occupancy would be the logical method.

?

What am I doing wrong?

?

I am hoping this single screenshot shows everything that needs to be seen to determine what I am doing wrong.

--

Heath @ Human[c]ity

Heath,

LogixNG has blocks, Logix does not.

Are you trying to "lock" turnouts within the JMRI context or the layout context. ?If turnouts can be set using fascia controls or from throttles, locking is not doable.

Within JMRI, turnouts can be set by clicking on turnout icons, running Routes, using the Turnout table. ?Automation tools set turnouts, although they normally check for occupancy.

Setting up Logix/LogixNG is simple. ?The turnout command is the trigger. ?When it occurs check the sensor/block status. ?If active/occupied, do something. ?The sensor/block state is not a trigger. ?

The "do something" can be a problem. ?The typical reaction is to send another turnout command to reverse the first one. ?But that would trigger the Logix/LogixNG. ?Now you have a loop. ?Now the logic becomes more complicated since you need to somehow know to ignore the attempt to set the turnout back to the initial state.

If you are creating all of your own logic and there is no external ability to set turnouts, then you can use indirect turnout setting via sensors. ?This way you don't need to "undo" a turnout command.

Dave Sand

Dave,

?

I am trying to lock the turnouts in JMRI when the block is occupied.?

Locally I am using tablets running panels via webserver. (No physical pushbuttons)
Eventually there might be a remote dispatcher.

?

I wonder if I can create a table with the blocks and turnouts and use LogixNG table tables. I am guessing this would be a simpler solution than creating a different Logix or LogixNG for each turnout. ?I need to look at the other thread about tables to see if I can reverse engineer it to apply to blocks and turnouts.?

Edit: I just reread your last paragraph several times about indirect turnout setting via sensor and I am not sure where this would get setup.?

In Logix, the trigger (if) was the sensor being occupied or not and the action was the turnout being locked (then) or unlocked (else). But it sounds like you are saying this doesn’t actually work.?

Are you saying that if a turnout is set as locked and the button on the panel is pushed to change the turnout, that the action of changing the turnout will persist until the turnout is unlocked or the turnout receives a different command?

?

Thanks

--

Heath @ Human[c]ity

Heath,

Other than NCE with certain accessory controllers, JMRI has no concept of locking turnouts.

LCC (Layout Command Control) can "veto" turnout changes at the hardware level. ?However, this requires installing another interface and moving switch machine control to LCC. ?This has a steep learning curve and additional costs.

Layout Editor can do what you want, but it is limited and not available when using web server.

This means that you need to design and implement your own locking solution. ?

Your approach appears to be setting a lock flag based on the block occupancy. ?The logic is easy and works fine. ?However, there is nothing in JMRI that says the turnout logic should "check" a lock flag. ?

What might be doable, is to use internal turnouts for panels, etc. ? The internal turnouts can trigger logic to check the lock flag, or even just the block, before passing along the request to real turnouts. ?This way the real switch machines don't start moving the points before the logic says ok.

Dave Sand

Interesting idea using the internal turnouts as a script to check occupancy before throwing the actual turnout.?

I think this will go on the back burner until I start updating my dispatcher panel and then I will implement at that time.?

Thanks for the guidance.?

--

Heath @ Human[c]ity