BRX High Speed Counter Monitoring?

[Bobby]

Hi all,
   Using the first Brick here and am wondering if there is something similar to the 'Monitor CTRIO Module'. Where I can see enable/disable outputs and see the counts pulsing?

[Bobby]

Okay, I think I figured out the fact that I will simply use data views and the counter structure to do what I need, my next issue is I put say $Counter1.acc or $Counter1.InhibitCount in a dataview and get no feedback. When I attempt to toggle ON the .InhibitCount I get a communication error Code = 6.

[Bobby]

And I solved this myself but figured I would put up the solution. I simply had to update my software from 2.1.2 to 2.1.4 and all is working now!

[BobO]

In answer to your first question, not yet. It's something we want to do, but due to the much tighter integration of HSIO into BRX and generally much easier usage, it's a lower priority than some other things.

[Bobby]

Bob,

  After playing around with it more it is growing on me! Only question I am having right now is on the old CTRIO modules I tied an output directly from the module to a clutch/brake controller and used preset tables for those outputs. I am thinking now I need to do the work in my logic and use one of the available high speed outputs?

[BobO]

Bob,

  After playing around with it more it is growing on me! Only question I am having right now is on the old CTRIO modules I tied an output directly from the module to a clutch/brake controller and used preset tables for those outputs. I am thinking now I need to do the work in my logic and use one of the available high speed outputs?

Table Driven Outputs...all in hardware. Way better than CTRIO. Look at the TDOPRESET and TDOPLS instructions.

[Bobby]

Bob,

  I found and setup a table driven output! It works great but I do have a question. Right now my table pulses on 'Y7' when an encoder reaches a setpoint. Y7 enables the "brake" of a clutch brake. I have it working with the counter, but I also need to pulse on Y7 at machine power-up since the clutch/brake controller defaults to "clutch" when powered on. Seems I am unable to control 'Y7' in the logic if it is tied to a 'Table Driven Output'?

[BobO]

We do not allow an output to be driven by more than one source...far too many things can go wrong.

An alternative approach to solving your problem would be to use a Match Register interrupt trigger and handle the output yourself. Be sure to use OUTI/RSTI/SETI in the interrupt routine.

[Mike Nash]

How about?:

TDODECFG - Deconfigure Table Driven Output

--------------------------------------------------------------------------------
 
Once a TDOPLS - Load Programmable Limit Switch Table for Table Drive Output or TDOPreset - Load Preset Table for Table Drive Output has been enabled for a Table Driven Output, it will assume exclusive control of that output point. Use the Deconfigure Table Driven Output (TDODECFG) instruction to unload the Preset table or PLS table and relinquish control of the Table Driven Output.

I haven't used any of the BRX Pulse Tables yet, so it's just a thought.
 

[BobO]

How about?:

TDODECFG - Deconfigure Table Driven Output

--------------------------------------------------------------------------------
 
Once a TDOPLS - Load Programmable Limit Switch Table for Table Drive Output or TDOPreset - Load Preset Table for Table Drive Output has been enabled for a Table Driven Output, it will assume exclusive control of that output point. Use the Deconfigure Table Driven Output (TDODECFG) instruction to unload the Preset table or PLS table and relinquish control of the Table Driven Output.

I haven't used any of the BRX Pulse Tables yet, so it's just a thought.
 

Won't help. The issue is that the physical output is bound to the TDO peripheral and cannot be dissociated without changing the I/O config.

[Mike Nash]

Won't help. The issue is that the physical output is bound to the TDO peripheral and cannot be dissociated without changing the I/O config.

Using a combination of Stage and TDODECFG and TDOPLS and TDOPreset, I could get a "reset" pulse to the Table output some of the time. Actually, I switched to two TDOPresets.

First, the help file on $HsCtrTmrx.ResetEdge and .ResetLevel looks fishy - like swapped.

Second, getting either to work seems to require luck or something. Sometimes edge would work, mostly not. ResetLevel seems to require holding it until I can verify that the .Acc matches the value I have loaded into the .ResetValue . I know there is a .AtResetValue, but I was faking the values since I am not on site with my BRX.

Third, I obviously don't have a handle on the On Success meaning in the TDO instructions.

Fourth, it works sometimes, but I don't know why it is or isn't.

Fifth, I'm quitting while I am ahead, this feels too familiar.

So Bobby, have you got a spare output you can safely parallel with the Table Driven one? Alternately, can you use the TDOPreset at zero position to do a timed output? You can pulse 1,000,000 uS for a one second pulse before starting. The TDOPLS might be more forgiving since it can do ranges rather than absolute points only.

[BobO]

Fifth, I'm quitting while I am ahead, this feels too familiar.

You're doing it again, aren't you.

First, the help file on $HsCtrTmrx.ResetEdge and .ResetLevel looks fishy - like swapped.

Second, getting either to work seems to require luck or something. Sometimes edge would work, mostly not. ResetLevel seems to require holding it until I can verify that the .Acc matches the value I have loaded into the .ResetValue . I know there is a .AtResetValue, but I was faking the values since I am not on site with my BRX.

Luck? Or understanding? I'm not sure what the help says, but I do know how those are supposed to work. Ctr.ResetLevel holds the timer or counter at the reset value for as long as it is active. Ctr.ResetEdge is a one-shot self clearing reset...you set it, the hardware clears it. They worked just fine last time I tested them.

Now this is likely the key: as a general rule, when you interact with a system resource through a structure, the changes are not applied to the hardware until the I/O update portion of the scan. Setting .ResetEdge or .ResetLevel doesn't do anything immediately.

Third, I obviously don't have a handle on the On Success meaning in the TDO instructions.

Fourth, it works sometimes, but I don't know why it is or isn't.

The TDO instructions simply load the hardware tables, and then signal success or failure. The instruction is not involved with the execution of the table after it is loaded.


My recommendation to Bobby remains. Use interrupt triggers.

[Mike Nash]

Yes the descriptions are reversed in help on the Resets. I figured the actual when they got written was my actual issue, but the comparisons made sure. I may look into that some more.

I moved the stages to their own program from Main and cleaned things up some and got predictable behavior. I am still working on my understanding of Stage. I'll get there. After this, the only thing that I would have issue with is using TDOPreset to pulse at a count of 0 will abort if count moves off zero. Holding the Reset for the startup duration would cover that.

Most of my Stage problems were due to trying to change the reset value within the stages to simulate the count changing since I can't hardwire it remotely to test. Once I split that out it was fine.

Stage does require more "stuff" but I'll admit it does handle the Axis and Table instructions more better than straight ladder. The best part is the status in the tree. The "On Success" does tend to require looking it up and reading it carefully. It would have been easier to read it than to figure it out on the fly, but I sorta skipped that this time.

It's not even my project, yet I feel compelled to go play some more. It's the paying jobs that aren't as fun, you have to make sure everything is right and finish it all the way on those.

[plcnut]

It's not even my project, yet I feel compelled to go play some more. It's the paying jobs that aren't as fun, you have to make sure everything is right and finish it all the way on those.

So I'm not the only one...

Also, I am a big fan of Stages. They require a little different mindset than RLL, but work really well for most projects I do.

[BobO]

Biggest key to stage is to use them for sequences...and only sequences. The biggest problem folks have with stage is they get in the mindset that they must use it everywhere. If your problem is A then B then C, use stage, otherwise ladder may be preferable. Stage is a tool. Always use the best tool.