Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Bobby on December 20, 2017, 02:53:26 PM
-
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?
-
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.
-
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!
-
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.
-
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?
-
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.
-
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'?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
All I ever use is stages. They get rid of all the one shots, etc. Program is less cluttered. Easy to follow through cause it tells you where to jump to for next step.
The biggest project I had, has 7 processes going on at the same time and stage made it much easier to handle. If I had to use RLL in my projects they look like a cluster xxxk. Biggest challenge i will admit is having them all come together to end the process.
The only time I do not use stages is in a program withing the program to do calculations or monitor faults. Not allowed to say exactly what i do, but we design and make our own machinery.
It is so surprising if we are forced to buy a machine, all the bugs in them. Sometimes the safety features are minimum or lacking. we run our machines months looking for bugs before we release them for production. Even get operators from the floor to run them and add, remove, modify features as needed. Engineers make the worse designers, lol. Over think things. I get humbled by the operators.
-
I get humbled by the operators.
Operators are my best friends.
-
Operators are our biggest problem. 30 years experience, one year repeated 30 times. First question on a fully automated system is “How do I do this manually” My answer to one operator was “Never Never Never, Not Ever, Never Never Never Never run that pump in manual”. Three days later he put the VFD in manual and melted down all the pvc piping! I told him “Sorry we can’t fix stupid.”
Last week he asked for a timer to tell him how long a system that runs 24/7/365 is turned off. I told him that according to the atomic clock at the national bureau of standards it runs exactly 24 hours 0 minutes 0.000 seconds every day!
-
Speaking of Stages, I have found a little glitch in them.
If I have an existing program on a PLC consisting of only ladder logic, and I "convert" it to Stage based by adding a Stage, S0, at the top of the program, and send it to the PLC, it will not run that S0 (and any other stages it may have triggered) until I manually go to Debug Code Block > Enable Stage.
Not a huge deal, something I can remember, but seems like a bug to me. FYI.
-
You will have to cycle the PLC from program to run before any stage will automatically enable.
-
You will have to cycle the PLC from program to run before any stage will automatically enable.
More specifically, a program block has to go from not running to running.
-
Speaking of Stages, I have found a little glitch in them.
If I have an existing program on a PLC consisting of only ladder logic, and I "convert" it to Stage based by adding a Stage, S0, at the top of the program, and send it to the PLC, it will not run that S0 (and any other stages it may have triggered) until I manually go to Debug Code Block > Enable Stage.
Not a huge deal, something I can remember, but seems like a bug to me. FYI.
Not a bug, but admittedly confusing. The initial stage is activated by the program block run initialization. If you add stages to $Main (which is always running) you have to cycle through program mode to start them (or use debug). Any other program block can be halted/run from code.
-
Also bears mentioning, I am one of the biggest stage fans on the planet, but I rarely use them in $Main. I'm not opposed to it, I just tend to use it as a supervisor for running programs and enabling tasks. I'll put initialization in $tFirstScan, so I don't really need a sequence in main. Not a big deal, just preference, but I also see many user programs coded the same way.
-
Big fan of stages here too. Used them extensively on the DL205. On the DoMore we have a membrane cleaning process with about 40 steps. Really easy to understand, debug and modify.