H2-ECOM100 Error Light

[franji1]

I just checked the code that's generated - it must see an OFF to ON transition.  There are also issues if the IBox does not get scanned on first-scan, which can be an issue within a Stage.  The Workspace register gets cleared on "first scan" for any IBox that has a "workspace" register.  However, if this instruction exists within a Stage, but that stage is not active on "the first scan", then it's going to initialize in a strange state.

You may want to clear the Workspace registers "on first scan" at the top of your ladder for the IBoxes that are used within a Stage.

[MarkTTU]

OK, the attached is what I've come up with that seems to work every time. I've got a 1s timer that essentially waits for the ECOMs to power up and let the ECOMs see an off to on transition. I've also got a 30s timer that will force the command with another off to on transition if it didn't work the first time. Thus far this code has proven reliable in testing. Anyone see issues with how I'm doing this?

[franji1]

OK, the attached is what I've come up with that seems to work every time. I've got a 1s timer that essentially waits for the ECOMs to power up and let the ECOMs see an off to on transition. I've also got a 30s timer that will force the command with another off to on transition if it didn't work the first time. Thus far this code has proven reliable in testing. Anyone see issues with how I'm doing this?

I would NOT do the 30s timer.  Just check all of the success and error bits.  If all the success bits are ON, it's succesful (even if it took 1 minute).  Otherwise, if any of the error bits are on, you have a bad/missing module.  If you want to speed it up, since you have 3 ECOM100 modules, you can configure these 3 simultaneously, not serially.

[MarkTTU]

I've got them all setup to do it simultaneously. The only issue I have with not using the 30s timer (even if its 60s or 90s or whatever) is that sometimes neither the success bit nor the error bit comes on. In those cases I have to have a way to try again or my program will just hang.

[franji1]

That's fixing the symptom.

On first scan, clear all of the workspace parameters of the IBoxes that are used in S1.

STR SP0
LD K0
OUT V711
OUT V713
OUT V715
OUT V717
OUT V721
OUT V723
OUT V725
OUT V727
OUT V731
OUT V(see my ECRDMID below)

Then do something like READING the Module ID and retry that until it works in Stage 100, THEN jump to S1

SG S100
TMR T100 K10
STR T100
ECRDMID

STR Success
JMP S1

STR Failure
RST T100  // just reset the timer to try reading again

This way, you're READING to see if the module is OK, not Writing.  No flash writes.  You could stick the workspace clears in S100 and do them unconditionally, instead of on first scan at the top of your code.

[MarkTTU]

That's fixing the symptom.

Ya, I know, but its been the best thing I could come up with.

On first scan, clear all of the workspace parameters of the IBoxes that are used in S1.
...
You could stick the workspace clears in S100 and do them unconditionally, instead of on first scan at the top of your code.

I've always assumed I should leave those alone, but I guess not. Wouldn't weird things start happening if I'm clearing those VMEMs every scan?

Then do something like READING the Module ID and retry that until it works in Stage 100, THEN jump to S1

This way, you're READING to see if the module is OK, not Writing.  No flash writes.

I've done that in another program. In that one I read the module ID as set by the DIP switches and then set the appropriate IP address. Even there I still have the issue; even after reading the module ID sometimes I get neither success nor error when writing an IP.

Its almost like sometimes the backplane drops some data transfer that was supposed to make it from the 260 to the ECOM or vice-versa.

[Greg]

marksji, OK, but if you pile up writes to the flashROM, then you'll have a worse thing happen... the red light you were experiencing before. How about if it doesn't work after 30 seconds (or perhaps longer) that instead of retrying automatically, that you set some kind of error flag, let the "operator" know initialization of the ECOM100 didn't work as expected and manually chose what to do. What do you think?

[franji1]

The key issue is that the workspace parameter of these IBoxes are not being executed on the first scan (SP0) because they are used in Stages.  Hence, their "old" values are there whenever you go back to RUN mode (after a new download, program to run transition), meaning that whatever IBox thinks it "had the token" (or whatever state it was in), will continue to think "it has the token" when it "starts" executing, when it really doesn't, and will be waiting for a response in ITS error code parameter, but it will never see it because it really doesn't have the token, and it will be "hung".

The IBoxes were designed to work with Ladder, but are not "stage aware".  This is something we've done with MX and made many of these "IBox" type "native" instructions be VERY "stage aware" in MX.  Stage awareness is something that must be designed up-front at the firmware leve.  IBoxes are just Ladder Macros, so in 450/260/250/06/05-land, there are some limitations.  In MX-land, it's gonna be GOOD.

If you do the RESET of the workspace registers in an S100 stage (with the READ MODULE ID IBox), that should "reset" your S1 IBoxes so they "never" hang (except for a bad or missing module).

[MarkTTU]

Based on what I'm reading here, what if I just stick these at the top of my program and let them be what fires off my initial stage? From experience I know I'll have to wait for the ECOM to get powered up for a couple of seconds, but after that I could just wait. I think I could probably program something that's pure C-More where if the C-More sits on my "splash" screen for more than x seconds a message pops up letting the user know they need to power cycle the PLC...

[franji1]

ISG or at top of your program above all stages (but driven by a single, leading edge event), that code would work.  When it's in a non-ISG stage or not part of the "main" ladder scan, then the IBoxes don't get a chance to re-set on Program->Run transition, so you end up with IBoxes initially in "strange states", i.e. "hanging".

[MarkTTU]

So if inside my ISG stage (first stage in the ladder) I'm using SP0 to fire my ECOM setup stage (immediately follows my ISG stage) then I should be ok?

[franji1]

Yup, since it is below the ISG in your ladder

[MarkTTU]

Cool. I'll do that then since its already almost written that way anyway. Easy fix.