Eprom problem 2

[powerjunx]

Hello, i got a controller having 2 EPROM (SST27SF020-70-3C-PH), CPU and EEPROM.

Already confirm good condition of terminal connections as well as simulation test of I/O's thru keypad input.

What i found is that the system never responds to the operational keypad input (such as starting a fan or motor). How can i conclude if EPROM has failed? or any software related issues.

Your comments plz.

"..the more, the merrier" Genghis Khan

 

[MikeHalloran]

You first verify that the keypad itself is working, with a logic probe, or oscilloscope, or LEDs tack-soldered at appropriate points.

Try reading the EPROM in a programmer.
Successful read suggests the EPROM is ok.
Successful compare with the stored binary image of the EPROM suggests more strongly that it's ok.

One of my favorite embedded tools is an EPROM simulator, which lets you quickly load, well, anything, into the target memory space, so you can create and run any special test that you can conjecture.





Mike Halloran
Pembroke Pines, FL, USA

 

[itsmoked]

Remember that EPROMs forget. After about 10 years you're on questionable ground. The EPROM can be just fine but have "forgotten".

Perfect built-in obsolescence.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[MikeHalloran]

Keith makes a good point. How old is the controller?

Also, lots of very different controllers could have two EPROMs, one EEPROM, and a CPU. Can you identify which particular controller it is?

Mike Halloran
Pembroke Pines, FL, USA

 

[powerjunx]

Thanks for your reply. Mike, it is a unisab II controller for Aalborg Marine Boiler. Good point for such device you mention however i am solely dependent on operational observation of the boiler status and diagnostic functions. According to data sheet, such EPROM has 2MB capacity and the controller has PID loops.

Thank you as well Keith. The unit has spend over 7 years.. but i had notice lots of spare EPROMs having lower version on scrap box. i suspect this was upgraded 4 times during its lifespan, according to spare old EPROM.

Keith good point, EPROM forgetfulness is what i am trying to dig out. When i simulate from diagnostic function for activating outputs it's working fine. However, when a command keypad input the controller never responded. I already replaced PCB relay cards and cPU card yet problem still persist. Can i conclude this EPROM has impending trouble? and it's time to install new one or upgraded EProm?




"..the more, the merrier" Genghis Khan

 

[MikeHalloran]

Odd; I find references to the unisab II as a controller for refrigeration compressors, not marine boilers. ... which means those EPROMs may be 'very special'.




Mike Halloran
Pembroke Pines, FL, USA

 

[powerjunx]

yeah very odd indeed. unisab II maker SABROE was bought by YORK Refrigeration. Aalborg boilers MISSION OC were fitted with this kind of controllers.

Mike, my guess is that this EPROM was packed with different SW preloaded program. I scrolled down and hard reset the controller. Upon restart, after "COPY EEPROM YES" I notice there are about 5 different boiler model configurations inside.

i may post later the PCB.

"..the more, the merrier" Genghis Khan

 

[MikeHalloran]

I found a York document 1021.pdf, internally titled
{
Instruction for replacement
of components in UNISAB II
- for compressors
}

It suggests that the EPROMs each contain the base program in an assortment of languages, and that the CPU runs from the EEPROM, with local/language-appropriate copy of one of the programs in one of the EPROMs, and also stores local data like serial numbers and maybe setpoints in the EEPROM. I.e., once set up, it should be able to run with the EPROMs removed, but the EEPROM is essential.

There is also a battery, which may need changing.

I think EEPROMs have a limited life, so replacing the EEPROM with a blank one and going through the initial setup might get you up and running.

I could not find a photograph of the interior. The drawn illustrations in the manual I found suggest that the keypad is joined to the CPU 'print' by a ribbon cable, and probably a cheap connector. Ribbon cables don't last forever, especially if they're flexed, so a close visual inspection and continuity check would be a good idea.






Mike Halloran
Pembroke Pines, FL, USA

 

[powerjunx]

Hello Mike.. here's the EEPROM and CPU card.

"..the more, the merrier" Genghis Khan

 

[powerjunx]

Here's the complete set of the controller.
If you think that replacing EEPROM would solve the issue. Then that's one thing for sure i miss! need to replace that EEPROM.


"..the more, the merrier" Genghis Khan

 

[MikeHalloran]

I'm thinking it's got to be pretty cheap to replace the EEPROM, provided that you're prepared to do a cold start from scratch with a blank EEPROM; I don't know how complicated that is, or whether your records will be adequate to fill in the needed data that isn't automatically filled in.

Note that going from "keypad doesn't work" to "EEPROM worn out" or "EPROM funky" is kind of a long leap. I personally would prefer to verify each module/link is {okay|not_okay} in a linear fashion starting at the keypad, or better, at the power source for the keypad.

It appears that the keypad connector is a two-row pin header without latching means, suggesting that the keypad is connected by a ribbon cable with IDC connectors. I think that the interface between IDC connectors and the cable conductors does eventually degrade, and the unit in question is not new, so it might be worthwhile to try replacing the keypad cable, if you can't easily verify continuity from end to end as installed.

... but wait; let's back up a bit.
You said in your first message that you can individually control the i/o points, or simulations of the i/o points, from the keypad.
So the first question that should be answered is "What's different?". I.e., when you 'test' the i/o points from the keypad, does that use a different circuit in the keypad, or anywhere else, than actually exercising the i/o points for real?

If, e.g., the keypad communicates only with the CPU, over the same conductors all the time, i.e. the keypad does not have special test circuitry, then we can tentatively assume the keypad is okay, and the next thing to suspect and test is the i/o relay 'print', which is probably fused (check the fuse(s)!) or the connection from the CPU 'print' to the i/o relay 'print'.





Mike Halloran
Pembroke Pines, FL, USA

 

[powerjunx]

Thank you Mike.

I have the configuration default setting from makers compiled in the instruction manual. I got same EEPROM from new spare attach on CPU print. As you had suggested, i am planning to install and mount it to the cpu print. Though it takes time, I guess i am going to manually keying-in the configuration data to this blank EEPROM.

If i don't succeed with this blank EEPROM, can i use back the old one with previous data unchanged? What would i expect upon restart with this blank new EEPROM?

A brief view of this controller; it is a slave connected to a PC workstation RS-485 comm as well connected to master controller. It controls 2 Fuel motor pumps (auto/stand by/stop modes), 1 burner fan/blower, 2 fuel electric heaters, 1 dosing chemical pump, reads analog fuel temp and pressure and digital I/O's.

The controller contains diagnostic functions: Monitoring i/o status (digital and analog) as well as Output test function. Example: To verify motor pump control circuit, simply activate the Digital Output test thru keypad command on a particular device actuates the relay and that confirms the loop is working. Herein i disregard keypad defects.

However, during operation, the controller output is inactive (pump) when i select auto mode (thru keypad) it returns to stop mode. Before this whole breakdown, i had notice the controller has intermittent communication failure, prompt stopping of pump/fan without a cause, etc. I may assume that EPROM has been on the state of dementia as keith suggested: "..Perfect built-in obsolescence."

As shown from posted attach file..all circuit boards as well as keypad and LCD were replaced except EEPROM, 2 EPROM and CPU

N.B: Keypad integral to the front panel (4 arrows, set, and left side keys, see pics.

Your thoughts, please.

"..the more, the merrier" Genghis Khan

 

[MikeHalloran]

Wow, you've replaced everything but the hood ornament, and it's still possessed!

Long shot: If the EPROMs contain an assortment of language specific programs, as in the compressor controller I found, it might be worth a try to load one of the programs from the _other_ EPROM.

Or call an exorcist.


Mike Halloran
Pembroke Pines, FL, USA

 

[powerjunx]

Yeah, Mike you are right. I don't want to explore the unknown. I bet, it is time to call the service expert.
Thank you for your comments. You have shared another good insights.

"..the more, the merrier" Genghis Khan

 

[itsmoked]

Any one forgotten memory location can bring the whole thing down in a pile.

When I worked at a company that sold ETO sterilizers, that were EPROM based, we had a process by which every five years we'd get the EPROMs back, read them out and re-write them. All our customers cycled their EPROMs thru us. A lot of them kept a spare set.

One thing you can try is to read out the EPROM with a programmer. Often a programmer may read them out when they don't read out by the processor in 120ns.

Maybe you can find a 'fellow boiler' with the same unit. He will be facing the same outcome eventually/soon. You could read his out and save the HEX file at both sites. Use it to reprogram yours or better yet, make a new set. Then keep a set you can both use when a problem comes up again.

Reading thru this thread I didn't see if the company is defunct or not. If not they should have this entire issue down pat.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[powerjunx]

Thanks, Keith. Thinking of your comments.

Unfortunately, i don't have access to EPROM programmer.

I realized that these controller were 16 units in operation. I believe a spare set is somewhere hidden. Luckily, I just found 2 spare EPROM on the shelf.. All labeled and scribbled with same version. Though i tried to installed EPROMs but still my effort has failed. The problem remains the same. Could this be a hardware related defects?

I opted to stop my pursuit until technical assistance arrive.

I had requested new controller with EPROM having same version from old unit. Or should i request upgrading the EPROM to a new version?

Your thoughts please.

"..the more, the merrier" Genghis Khan

 

[MikeHalloran]

It apparently is a problem other than the EPROM.
The specialist should be able to diagnose it quickly, if (s)he bothers, instead of just replacing the whole box.

[highlight #FCE94F][/highlight]



Mike Halloran
Pembroke Pines, FL, USA

 

[itsmoked]

If you are happy with the correct operation (when the unit was running) I'd probably ask for the same revision so there is no mongrel in your herd. I'd also get a NEW copy of the EPROMs while you have their focus.



Keith Cress
kcress -

http://www.flaminsystems.com