ECOM100 Blinking Red Light

[ATU]

I was trying to update the firmware in an ECOM100 module. I got an error message and the module lights were blinking rapidly and I couldn't get the module to come up in NETEDIT. So I waited several minutes and then powered down. When I powered back up, I have the red blinking light of death.  Is there anyway to bring it back?

Also, the reason I tried to update the firmware is that I was having random errors using the IBOX ECRX instructions. I was trying to simultaneously read 2 different memory locations from the same slave in one stage. Even if you use different workspace parameters, you can't do this?  Once I used the success bits to interlock it, it worked.

[BobO]

It's in the bootloader, you can still talk to it. Not sure if there are any limitations or not. It should still communicate though. Somebody who actually knows what he is talking about wish to comment?

[ATU]

Netedit doesn't see it.

[BobO]

I just tried it. It saw mine ok and was able to repair the damage.

If you are using IP on Win7 and the IP address is bad (for whatever reason), NetEdit won't be able to see it. IPX on XP should be able to cut through whatever haze is there...

[ATU]

Yes! I see it under IPX, it shows firmware REV 0 and Rev 4.0.165 for the Boot. Isn't that the latest boot?

[BobO]

Sounds right.

[ATU]

Its Alive!  Its Alive!

Question, I set the IP address to a different sub net with my laptop in XP then what I have on the office network. When I put it in the rack with the MX CPU in my office, I ran Netedit in Windows7, it doesn't see it in the TCP/IP tab. IPX doesn't work, I get a winsock error.  What do you do in that situation to set up the module, if you don't have XP available?

[BobO]

I believe there is a magic dip switch setting to reset the IP address. Not sure what it is though...sorry. One of the other guys knows, I'm sure.

[franji1]

I was having random errors using the IBOX ECRX instructions. I was trying to simultaneously read 2 different memory locations from the same slave in one stage. Even if you use different workspace parameters, you can't do this?  Once I used the success bits to interlock it, it worked.

You should be able to do
STR ST1 // always on
ECRX Success1
ECRX Success2
STR Success1
AND Success2
JMP (or whatever)
RST Success1
RST Success2

Note that DL IBox outputs are NOT automagically reset when you exit a stage with an IBox (different than our new CPU), hence I added the two RST instructions (could have been one RST with a range if they were contiguous).

[ATU]

I had some really strange things happen. Every once in a while, the Ibox would do nothing. No Success or no Fault. It would just sit there until I did a P/R transition.  Called AD tech support and they told me that it was a bad idea to have them down in stages that turn off and on because it would mess up the token?  So I am moving all the ECRX and ECWX instructions above the stages a and let the stages look for a transition on the success bits to know when the data is updated. I'll reset the Success/Fail bits at the bottom of the program.

So this is going to change with the MX CPU? I noticed that you don't have to configure it in NETEDIT and enter IP addresses directly in the instruction. I like that.  That's thinking more like an OEM.

[franji1]

IBoxes are just macros - they have to execute on first scan (I forgot about that), so sticking them in stages are usually a bad idea.  You could hack around that by having ALL your "workspace" Stage-based IBox's V registers in a contigous V block then CLEAR that memory on first can, otherwise they will maintain their state after run->pgm then back to run.  This is - they need to be reset on first scan, which the IBox logic DOES, except if it is in a stage, then the IBox never gets a chance to be "scanned" on first scan, hence it never resets  .  So tech is correct about that (without my hack mentioned above - but it is a hack).

HOWEVER, the new CPU we've been working on has these operations as built-in instructions, hence they reset automagically on pgm->run and also when you transition out of a stage that contains them (kind of like how OUT coils turn off in DL Stages).

[ATU]

My preference is not to have the communications polling 24/7. It wastes cycle time in the CPU and in the slave devices, not to mention unnecessary network traffic. However, I put all the IBOXs at the top of the program today and the com problems pretty much went away.

[BobO]

As Mark mentioned, in the new CPU stuff like this works like it should...in stages and everywhere else. Don't give up on proper program design techniques just yet.

[franji1]

As Mark mentioned, in the new CPU stuff like this works like it should...in stages and everywhere else. Don't give up on proper program design techniques just yet.

Yet another reason the new CPU will be easier to program than existing DL CPUs.  But with your "classic" systems, you still gotta do what you gotta do  .

[rswolff]

I've had LOTS and LOTS of problems with my ECOM's.....seems they are fine if you use one....and don't do much with it....tie more together and they definitely start to have problems.....and they really, really like to disconnect from the cpu(?).....too many messages....too small a stack....who knows? if I could I'd take the nine(9) I have with the D0-06 plc's and toss them in the garbage....where they should have been in the first place....If I knew about the 'hidden' timeout problems and lockouts beforehand I would have used something else....cost would not have been a concern as I've already spent thousands trying to find workarounds to fix the inherent problems with these modules in a network setting.
bob