Hoobs

MrPLC Member
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Hoobs

  • Rank
    Sparky

Profile Information

  • Country United States

Recent Profile Visitors

2156 profile views
  1. @innoaloe, Thanks for that pointer.  I had discovered this as well, and it does what it is supposed to but, as you state, it's not really what I'm looking for. @Crossbow, It's been a little while but I remember 6-7 years ago working on an A-B unit that had the type of WDT I was expecting to see on the OMRON units.  This approach to WDT comes from embedded industrial microprocessor control technology of the last couple decades, where an on-board WDT has options for what to do if it gets triggered: full system reset (like a power cycle), reset only some system components (i.e., reset a network port/stack, reset a potentially stuck I/O module, etc.), and/or simply jump to a specific machine instruction address and execute from there.  It's not that software can reset the WDT (which is pretty pointless in most real-world situations because the software is likely not even executing in a predictable manner any more).   Rather,  the WDT has on-board ability to take specified action that can recover the system functionality and allow normal processing to continue from that point forward.  Of course, this requires that the up-front engineering work correctly designs how to identify that the system is in a state that requires the WDT to take action. I could do the external hardware design you're talking about, it's not difficult, but I was expecting this kind of functionality to be on-board, otherwise the WDT is essentially useless for recovery of a locked-up system.  If I have to do something external I'll instead stick in an IP-controlled switched outlet, and have my production proxy server (which expects a ping from the PLC every 500ms) to use that IP-controlled switched outlet to force a power-cycle.  It's kinda brute force, but it should get the job done. ASSUMING the implementation bug(s) in the AC_StepProgram instruction don't get in my way (subject of a different thread).  My regional OMRON field engineer is supposed to be here next week so I can show him how the AC_StepProgram instruction is not coming up in a stable state after a power cycle of the PLC, making full recovery/restart of the affected control processes impossible.  If we can get that issue figured out, then I should be able to correctly bring the system back up after a power hit.  If I can get to that point, I can then use that capability to also be the WDT/locked-up recovery approach. Thanks guys! Hoobs
  2. Am I the only person on the OMRON forum these days who is using the AC_StepProgram instruction?  If anybody else is using it, and is getting success, please let me know here or PM me. I'm using it heavily, and I currently believe there is a bug (or multiple bugs) that are preventing this instruction from correctly recovering after an unexpected power cycle.  I have also failed to ever see the StartAtPV option to the instruction ever do what it is advertised to do.  I'd like to hear what other folks are doing with this instruction, and if anybody has tried to put together a power hit recovery strategy for a system that includes this instruction.. Thanks! Hoobs
  3. Thanks guys!  Makes sense now...  I was so buried down in ST-land I forgot to look up at the IDE and see that I had to define them first in the multi-view.  DOH! Hoobs
  4. Wow...  that's surprising.  I must be missing something then...  what is it good for as currently implemented?  Without the ability to take asynchronous recovery action, that is not dependent on proper code execution occurring, the WDT doesn't strike me as useful.  What do I not see? Thanks, Hoobs
  5. It always depends on the situation.  On my current project, it would be far more dangerous to let the operator continue processing with the PLC hung than with it being reset.  In this particular case the hardware was specifically designed to be handled this way, and if a keepalive pulse generated out of the main loop doesn't arrive on schedule the hardware could also initiate a reset externally.  In either case the hardware correctly locks out the operator console until well after the system is fully backup and a positive status position is established.
  6. I would like to explicitly utilize the cpu watchdog timer to not only determine when the CPU is hung/stuck, but then execute a cpu reset.  Other PLCs I have used expose a config setting where you can choose a timelimit for the watchdog timer and, if that time limit is exceeded, there is independent hardware that sees this and causes a cpu reset to occur. In my NJ501, I see in the docs that there is a watchdog time (WDT), but I can't find any information about configuring it, or utilizing it as part of a state identification and recovery strategy. Anybody else doing something like this with the WDT?  How? Thanks! Hoobs
  7. Sorry for such a noob question, but I'm still figuring out the OMRON-specific  implementation details for ST...    I can't find anywhere what the language syntax is to define a function or function block of my own in ST.  I can see how to do it in ladder, but I'd rather do it in ST because I will be calling it from ST as opposed to ladder. The "standard" way is with a FUNCTION_BLOCK keyword, etc., but the OMRON NJ series doesn't seem to know anything about this syntax, either in-line or in a function or function block that's been added to the project. How do I define my own function or function block in ST? Thanks! --Hoobs
  8. Thanks Inoaloe!  It turns out in my situation I'll not have things set up that way, so I'm going to try to just have a single one of these structures, set to be a constant, and see what happens.  If it doesn't work, I'll report back here.
  9. NJ501-1300 Has anybody started using the (relatively new) instruction on the NJ/NX series, AC_StepProgram? There is a structure variable used to provide the details of all steps of all programs (profiles) that you would want AC_StepProgram to manage.  It will calculate ramps, holds, soaks, etc., and move the setpoint around as necessary to implement each program/profile.  If ya need to do these things, it looks like a *big* headstart...  I'm glad I found it before I wrote a pile of code to do the same things! My question: The structure variable used to provide the details of all the steps is an InOut variable.  For the life of me I can't figure out why, or if there is any scenario where the instruction would actually change anything in that structure.  There are other variables that I believe are all it needs to maintain state between task cycles.  Does anybody know why this is an InOut variable instead of just an In variable? If you're wondering: This is important to me because I'm building a system to control several dozen closed loop furnace systems.  If need be I will replicate all 5 of my processing profiles to each one of the loops, but I was hoping to avoid that if AC_StepProgram doesn't actually change anything in the structure. Thanks! Hoobs
  10. Figured this out, just want to be sure it's documented here. It turns out there are two input variables to PIDAT that are structures, one holds initial setup parameters and the other holds on-going operational parameters.  Things like max/min ranges, some operational preferences, etc.  Well, it further turns out that the default values for the items in these structures are such that the PIDAT instruction is guaranteed not to function correctly.  If you define those two variables, and set up their initial values correctly for your situation, PIDAT should spring to life even if there are no autotune cycles that have been performed. Hoobs.
  11. NJ501-1300 Question specific to PIDAT...   in the W502 manual (instructions reference) I find the following statements buried down in the descriptions of all the variables, specifically the variable ATDone, which is the outgoing signal leaving to enable the next instruction to the right on this rung: My question is: How do I get the PIDAT instruction into the state of "PID control is in progress without autotuning"?  If the value of the StartAT input is false, then ATDone will never go true.  However, if StartAT is true, then the instruction is going to start an autotune cycle, which I don't want.  There is no description I can find for how to get it to do "PID control without an autotune cycle having been completed".  The timing diagrams aren't making this apparent either, unless I'm not seeing it. Thoughts? Thanks! Hoobs
  12. Perfect, that's what I believed looking at the docs, thanks!  It's not a problem, as I can keep all my fb_PIDATxx instances in an array indexed by loop number, so they are easy to get to. Al  
  13. NJ501-1300, with a pile of TS3101 analog input modules and OD5256 digital output modules. First, a general question: Are NJ function blocks reentrant as a rule?  No?  Sometimes? Second, a specific question:  I am setting up this NJ-based system to perform multiple (42, for now) temperature control loops.  Each control loop must obviously be able to run independently.  As I am intending to use the PIDAT function block to handle PID duties, it raises a question: Is the PIDAT function block reentrant?  If so, how would it keep track of different sets of PID coefficients, and everything else it would need to keep multiple invocations straight?  I don't see how it can do this, but maybe I'm missing something. My current belief is that it doesn't do this, and that I will need one instance of PIDAT for each control loop, i.e., 42 instances, with distinct sets of variables for each one.  Is this correct? Thanks! --Hoobs
  14. No, I had not discovered that here in my early days with Sysmac Studio, that will be extremely helpful -- thanks!!! Regards, --Al
  15. Innoaloe, thanks very much for digging back into this with me, I appreciate it.  Two thoughts: Even though it doesn't affect me, the 60-second hold-off with SktTCPConnect still doesn't make sense to me.  Why would the controller enforce such a hold-off? Your point I quoted above: This is unusual to me, I'm really lucky I had a chance to learn this early in my NJ experience.  I expected these blocks to be reentrant, but that is obviously not the case if the Execute in-parm has to be forced to cycle through False to reset a block before it can be executed again.  I can work with it, this is just different from some other situations I've been in where blocks could be re-executed on subsequent passes without this requirement being in place. Thanks!--Al