Host Engineering Forum
General Category => ECOMs and ECOM100s => Topic started by: ATU on June 20, 2012, 07:16:41 PM
-
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.
-
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?
-
Netedit doesn't see it.
-
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...
-
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?
-
Sounds right.
-
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?
-
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.
-
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).
-
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.
-
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).
-
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.
-
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. ;)
-
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 ;D.
-
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 >:(
-
rswolff,
You complained about this 16 months ago. We (I) asked you some technical questions.
See here: http://forum.hosteng.com/index.php/topic,722.msg5454.html#msg5454
You disappear without answering. You then reappear 16 months later only to complain again; on two threads; one not even related. ??? I would like to know if you, personally, have the ability to look into a crystal ball and see your own customers' problems and fix them without data. I find that I do not have that gift. ;D
So, if you are serious about fixing your issues (which I personally AM VERY INTERESTED IN; it is both my delight and job), then I need all the technical details you can provide. Such as:
(1) Physical layout of your system.
(2) Data layout of your system (what talks to what).
(3) Exact symptoms (What happens?)
(4) Procedure (What were you doing when it fails?)
(5) Wireshark traces if you think they might help.
I have worked long enough with these engineers at Host to tell you that the VERY DAY we can duplicate (or at least understand) the issue, it will be fixed if humanly possible.
So, how 'bout it? Will you help me help you? Or will you just wait another year or so and complain again?
-
and oh yeah.....Win7 is REALLY REALLY REALLY good....if all you want is a Facebook page and videos from YouTube....and don't forget that really important function of organizing all your pictures, songs and whatever for you automatically......for everything else it basically is a piece of [fill in your own expletive]. bob ::)
-
Ummm....I'm confused.
-
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 >:(
Bob, my personal experience with using ECOM's (mostly ECOM-100's in fact) for multiple simultaneous functions has been quite good. Admittedly, I don't have any networks that tie nine PLC's together, nor any based on multiple 05/06 CPU's, but the ones that I do have run without stumbling, day after day, year after year. I simply NEVER have had any complaints from my customers over this issue. So, while anything less than perfect, trouble-free performance can be maddeningly frustrating, I don't think it's fair to act as if the product is just a pile of junk. It seems to function well at some sites and not at others, possibly due to factors no one can identify yet.
-
Even AB has limitations with Ethernet Communications. No matter what PLC you are using, you can't have a dozen devices on one network all trying to communicate as fast as they can with everyone else, without some consequences. There isn't infinite CPU time nor infinite bandwidth. To me, it sounds like you need a master device to act as a traffic cop. However, if you would put your ranting aside and want to seriously solve your problem, I would suggest to first answer Greg's questions let them and others with some experience to try to help you. There is always a work around to most problems.
-
That's something I was going to suggest too, ATU. Have one of the PLC's (or a PC) act as the master and initiate all comms with all the other units, both reading and writing, even brokering data it itself has no need for. If you don't want to risk the single point of failure, program two or more units to do so, and have the backup(s) watch the behavior of the primary and take over the master role if they observe that it stops polling.