This post is specifically designed to discuss the Salwico Consilium Fire Alarm System. If you have any problems with this system, please leave a comment below, and I'll try to help. For more information on the system, I recommend reading the article: "Salwico Consilium Fire Alarm System. Troubleshooting".
Comments in that article are closed because there were so many of them, and that's why this separate article was created.
Here is a summary of the article “Fire alarm system Salwico Consilium. Troubleshooting”.
Fire Alarm System Salwico Consilium – Troubleshooting Experience
The article presents practical field troubleshooting on a 10+ year old Salwico Consilium fire alarm system, focusing on how to systematically diagnose faults in chargers, batteries, loop wiring, SCIs, addressable devices, and loop modules.
1. Charger/Battery Faults — Error 158 “BATTERY CABLE / FUSE FAULT”
Observed Symptoms
- Persistent Error 158 pointing to CHARGERM 90.
- Battery fault did not appear, even though the charger fault was active.
- Physically, equipment was running in +30–40 °C environment.
Key Technical Points
- Salwico chargers are designed to work up to +55 °C, but aging components reduce thermal tolerance.
- High temperature increases:
- charger internal resistance,
- battery internal resistance,
- fuse/terminal heating,
- false detection of cable/fuse faults.
Diagnostics Performed
- Retightened and replaced battery cables.
- Measured voltage – batteries stable.
- Replaced the charger (DIP switches set correctly).
- Charger swap produced a new BATTERY FAULT, indicating the battery condition is borderline and affected by temperature.
Root Cause
- Thermal stress: The charger and batteries overheated, causing intermittent voltage anomalies and false current-sense readings.
Resolution
- Temporary: Install a fan inside the panel for cooling.
- Long-term: Replace:
- CHARGERM unit,
- Both batteries (old, degraded, sensitive to heat),
- Improve ventilation.
2. Loop Fault — Error 142 “CABLE BREAK NEGATIVE” on Loop 1
Observed Fault
- Loop 1 shows break on the negative conductor.
- System shows fault quickly after reset, indicating hard break or high resistance on the line.
Technical Diagnostics Method
The article uses the official Salwico loop troubleshooting method:
1. Isolate the loop by removing loop input/output at the module.
2. Bypass SCIs using manual jumpers (SCIs open when they sense overcurrent or wiring faults).
3. Measure resistances:
- (+) to (+)
- (–) to (–)
- cross resistance if needed.
These checks allow locating the faulty segment.
Root Cause Identified
- Not a cable fault.
- Two manual call points had severely oxidized contacts, causing:
- Intermittent breaks,
- High resistance on the negative side,
- Loop instability.
Final Solution
- Cleaned call-point contacts.
- Tightened and cleaned all intermediate terminal blocks.
- After cleaning, loop resistance returned to normal and error cleared.
3. Loop MX Module Replacement Test
Steps Taken
- Suspicion that Loop Module 1 had internal damage.
- Replaced with spare Loop MX Module No. 4.
- Configured DIP switches to match original address.
System Behavior
- After power cycle:
- System booted slowly.
- Loop initially failed to detect devices.
- After several minutes, devices slowly repopulated.
Conclusion
- The module itself was not faulty.
- Delayed device detection was a consequence of loop instability and previous cabling/contact issues, not the module.
4. Detector Contamination — Error 130 “DIRTY SENSOR”
Technical Mechanism
Salwico detectors have internal contamination measurement that monitors:
- Optical chamber transparency,
- Drift of sensor gain,
- Scattering coefficient changes.
Why the error appears
- Smoke, dust, engine-room contaminants,
- Lack of filter cleaning,
- Age of sensors (sensitivity drift).
Recommended Maintenance
- Clean detector chamber.
- If cleaning fails → replace detector.
- Use Salwico address programmer to set the correct address for replacement units.
5. General Troubleshooting Recommendations
Critical Technical Steps
- Always inspect power quality and charger output.
- Check panel temperature — thermal issues are common in bridge installations.
- Use SCIs to segment loops and find high-resistance zones.
- Perform resistance measurements in both polarities.
- Look for oxidized terminals — very common on older vessels.
- When replacing modules:
- Set correct DIP address,
- Ensure proper seating in the backplane,
- Reboot and wait for full polling cycle.
Common failure points in old Salwico systems
- Manual call points with corroded contacts,
- Loose or oxidized terminals,
- Aged CHARGERM units,
- Batteries with high internal resistance,
- Overheating due to poor ventilation,
- Contaminated optical smoke detectors.
6. Support and Documentation
Suggestions:
- Using official Salwico manuals for each subsystem.
- Joining “Marine Engineering Manuals” Telegram channel for additional configuration files and guides.
- Asking for help in comments—article is intended as a practical reference.
If you have any issues with this fire alarm system, I recommend discussing it in the comments section of this article. I'll try to help! See you there!
.jpg)
Hello. Could you tell me how to restore the fire alarm system?
ReplyDeleteError 84 on the monitor: Voltage error on the I/O card. Then, a minute later, another error: Error mini 50.
And after a quick reboot. And so on.
Please help. Sincerely, Alexey.
Hello.
DeleteI’ll explain this in a practical troubleshooting order, based on how Consilium / Salwico systems usually behave. Your symptoms are very typical of a power or I/O bus problem, not a software bug.
What the errors usually mean
Error 84 – Voltage error on I/O card
This means the system detects undervoltage or unstable voltage on one of the I/O cards (often 24 VDC supply or internal DC/DC conversion).
Common causes:
• Weak or failing 24 V power supply
• Bad I/O card (shorted component, overheating)
• Backplane / bus problem
• Short circuit or overload on external I/O wiring
• Loose connector
Error mini 50 (followed by reboot)
This is typically:
• CPU reset / watchdog reset
• Triggered by voltage drop, noise, or internal crash
In short:
Error 84 causes unstable voltage → CPU crashes → mini 50 → reboot → repeat.
Why rebooting does NOT help
A reboot temporarily clears the fault, but as soon as:
• the I/O card initializes
• outputs energize
• load appears on the power rail
the voltage drops again → crash loop.
Step-by-step recovery procedure (recommended order)
1. Check the 24 V DC power supply FIRST
This is critical.
• Measure 24 V at PSU output
• Measure 24 V directly on the I/O card terminals
• Watch voltage during startup
You are looking for:
• Drop below ~22 V
• Fluctuation when relays energize
If voltage drops → PSU or load problem.
2. Isolate the faulty I/O card
If possible:
1. Power OFF the system
2. Remove all I/O cards except one
3. Power ON
4. Observe:
• Does Error 84 disappear?
• Does reboot stop?
Then:
• Add cards one by one
• The faulty card will trigger the error immediately
Very common: one shorted I/O card drags down the whole bus
3. Disconnect external wiring from the I/O card
If removing cards is not possible:
• Leave I/O card installed
• Disconnect ALL field wiring (outputs, inputs)
• Power ON
If system becomes stable:
• The problem is external wiring or connected device
• Look for:
• Shorted solenoid
• Water ingress
• Wrong polarity
• Burned relay coil
4. Check backplane / connectors
• Reseat I/O cards
• Clean edge connectors
• Check for:
• Burn marks
• Bent pins
• Loose backplane screws (ground reference!)
Poor grounding causes exactly this behavior.
5. Check batteries (very important)
If batteries are connected:
• Disconnect batteries temporarily
• Run system only on PSU
• Weak batteries can cause:
• voltage collapse at load
• reboot loops
6. Thermal check
Touch test (carefully):
• I/O card overheating?
• DC/DC converter hot?
Overheating I/O card = internal failure → replacement required.
When replacement is unavoidable
Replace the I/O card if:
• Error 84 appears even with no field wiring
• Voltage is stable at PSU but drops only on that card
• System runs normally when that card is removed
Based on your description:
90% probability:
• Failing I/O card OR
• PSU cannot handle load anymore
10%:
• External short / wiring fault
• Backplane grounding issue
Hi sir. Can I ask you please about one Problem with Salwico? Got Salwico Consilium NSAC-1 System - all Loops have Manual Call Points NS-ACP and in few places is need to change by new Model MCP-A (The Company every time send only MCP-A, NO NS-ACP onboard). When I changed to MCP-A and connected wires according Manual (As connected NS-ACP (parallel connection)) the Control Panel have Alarm NO ANSWER, when I connected wires to MCP-A according Manual from MCP-A (In:1+ 2-, Out:3+ 4-) the Control Panel have Alarm Positive and Negative Cable Break.
ReplyDeleteSo, How to integrate a new MCP-A in the System? It's is need to configurate this new MCP in Software or not?
Hello. This is a known compatibility issue between old Salwico NS-ACP and new MCP-A devices on NSAC-1 / NS-A loop systems.
DeleteShort answer first:
MCP-A is NOT a direct plug-and-play replacement for NS-ACP on NSAC-1 loops.
It is not a software issue, and configuration alone will not solve it.
1. Why the problem happens
NS-ACP (old type)
• Passive / simple addressable device
• Internally wired for parallel loop connection
• The panel expects a fixed load and response type
• No internal loop isolator
MCP-A (new type)
• Designed for newer Salwico addressable protocols (CS4000 / newer NS systems)
• Has separate IN / OUT terminals
• Has internal electronics and loop isolator
• Expects series (through-loop) connection
• Communicates differently with the loop controller
Because of this:
• When wired parallel like NS-ACP → panel sees “NO ANSWER”
• When wired IN/OUT as per MCP-A manual → NSAC-1 loop supervision logic detects positive & negative cable break
This means:
The loop controller does not recognize MCP-A as a valid device type
2. Is software configuration required?
No – and this is important.
On NSAC-1 systems:
• Manual call points are not individually configurable
• There is no device type mapping for MCP-A
• You cannot “teach” the panel that MCP-A is an NS-ACP
So:
Firmware / software configuration will not fix this
CCP Tools / programming will not help
Addressing changes will not help
3. Correct and approved solutions
Option 1 (BEST): Use correct device
You must use:
• NS-ACP
or
• MCP specifically approved for NSAC-1
If the maker keeps sending MCP-A, you must request:
NS-ACP or NS-ACP-compatible MCP for NSAC-1
Option 2: Use Salwico interface / compatibility module (if available)
Some installations use:
• Addressable I/O module with
• Conventional MCP
Example:
• Conventional MCP → I/O module input
• I/O module is compatible with NSAC-1 loop
This depends on:
• Available spare modules onboard
• System approval by class
What will NOT work
• Mixing NS-ACP and MCP-A directly on same loop
• Parallel wiring of MCP-A
• Series wiring of MCP-A on NSAC-1
• Software configuration only
4. How to confirm this onboard (quick checks)
1. Check loop controller type
If NSAC-1 → MCP-A is incompatible
2. Check Salwico compatibility list
MCP-A is listed for newer panels, not NSAC-1
3. Observe faults:
• NO ANSWER → protocol mismatch
• +/– cable break → supervision logic mismatch
These symptoms exactly match your description.
5. Final conclusion
You cannot directly integrate MCP-A into an NSAC-1 system.
This is a hardware / protocol incompatibility, not a wiring or software issue.
Correct action:
• Request NS-ACP
• Or request approved interface solution
• Do not attempt further wiring variations (risk of loop instability)
Hi Sir good day, Could you help me please about our salwico consilium fire detection system. When we test the fire alarm in the accomodation by smoke sensor, The alarm activated on the Central Panel only but the general and fire door activated after 2 minutes even the alarm delay is Disabled(LED ON). If tested using manual call point everything is working normally only by smoke sensor we encounter a delay alarm of 2minutes on the General and fire door even if it is disbaled.
ReplyDelete
DeleteGood day. Yes, this is a known and confusing behavior on Salwico Consilium systems, and from your description the system is actually behaving by logic, not by fault.
Let’s break it down clearly.
What you are seeing (symptoms)
• Smoke detector activated
• Alarm appears immediately on the Central Panel
• General alarm + fire doors activate after ~2 minutes
• Manual Call Point (MCP)
• Everything activates immediately
• Alarm delay LED = ON (disabled)
→ but delay still happens only for smoke detectors
Key point (important)
On Salwico Consilium systems, Alarm Delay = OFF / Disabled usually applies to MCPs, not necessarily to automatic detectors.
Smoke detectors are often handled by Cause & Effect (C&E) logic with pre-alarm / investigation delay, which is separate from the MCP delay.
Why this happens
Most vessels are programmed like this (class / flag / company requirement):
Smoke detector logic
1. Smoke detector → Fire alarm on panel immediately
2. System enters Investigation / verification time (often 120 seconds)
3. If alarm is not acknowledged or reset:
• General alarm activates
• Fire doors close
• Other outputs activate
MCP logic
• MCP is considered confirmed fire
• No delay at all
• General alarm + doors activate immediately
So:
• Panel alarm ≠ General alarm
• Panel alarm is instant
• Outputs are delayed by C&E logic, not by the “Alarm Delay” button
Why the “Alarm Delay Disabled” LED is misleading
That LED usually controls:
• Manual call point delay
• Common alarm delay
• Sometimes only selected alarm groups
It does NOT override:
• Detector investigation timers
• Double-knock logic
• Zone-based delays
• Software C&E delays
That’s why MCP works normally and smoke does not.
What to check on the system
You (or service engineer) should check:
1. Cause & Effect configuration
Look for:
• “Investigation time”
• “Detector alarm delay”
• “Auto detector verification time”
• “Zone delay”
Typical values:
• 60 sec
• 120 sec (very common)
• 180 sec
2. Alarm type of smoke detectors
Check if smoke detectors are configured as:
• Fire
• Pre-alarm / Investigation
• Delayed fire
3. Output logic
Fire doors and GA may be programmed to activate on:
• “Confirmed fire”
• “Unacknowledged fire”
• “Second-stage fire”
Not on first detector alarm.
How to confirm quickly (simple onboard test)
Do this test:
1. Activate smoke detector
2. Immediately ACKNOWLEDGE the alarm on panel
3. Wait 2 minutes
Results:
• If GA & doors do NOT activate → system is in investigation mode
• If they activate anyway → fixed timer logic
This confirms it’s program logic, not hardware fault.
Is this a fault?
No.
This is normal configuration on many Salwico installations and usually required by:
• Class
• Flag
• Company SMS
Especially in accommodation areas.
When it is a problem
Only if:
• Delay time does not match documentation
• Delay happens even for MCP
• Delay is longer than programmed
• Behavior changed without software changes
Hello sir good day, i tried the test that you've mention above and this are the result:
ReplyDelete•Testing
1. Activate smoke detector
2. Immediately ACKNOWLEDGE the alarm on panel
3. Wait 2 minutes
•The Result
=GA & doors do NOT activate
Another Test i've made to confirm :
-I've tried Disabled Alarm Delay(LED ON): ✓Activate each deck MCP and all instantly activated the GA&DOORS.
-I've tried Enabled Alarm Delay(LED OFF):
✓Activate each deck MCP and all instantly activated the GA&DOORS.
Remarks: MCP logic as you mention:
• MCP is considered confirmed fire ✓
• No delay at all ✓
• General alarm + doors activate immediately ✓
For the SMOKE sensor in all Deck level
@Disabled Alarm Delay(LED ON)
Central Panel Instant Alarm
GA&Door activates AFTER 2MINUTES
@Enabled Alarm Delay(LED OFF)
Central Panel Instant Alarm
GA&Door activates AFTER 2MINUTES
As you've mention above, i only see in the panel the "Cause and Effect of Test Mode"
I think i can have only limited access on the system.
Good day. Thank you for doing the tests properly — your results are very clear, and they actually confirm the root cause 100%.
DeleteFinal diagnosis (based on your tests)
This is NOT a fault.
This is fixed Cause & Effect logic for automatic detectors.
Your tests prove all of the following:
1. Investigation mode is confirmed
You did:
• Smoke detector → alarm
• Immediate ACK
• Wait 2 minutes
• GA & doors did NOT activate
This is textbook investigation / first-stage fire logic.
The system is intentionally waiting for:
• No ACK, or
• Time expiry (≈120 s), or
• Second confirmation (another detector / MCP)
Only then it escalates.
2. Alarm Delay button is irrelevant for smoke detectors
You tested both states:
• Alarm Delay Disabled (LED ON)
• Alarm Delay Enabled (LED OFF)
Result is identical for smoke detectors.
This proves:
• That button only applies to MCP or common alarm delay
• It does not override detector C&E timers
This is exactly how Salwico systems are designed.
3. MCP logic is correct and clean
Your MCP tests show:
• No delay in any mode
• GA & doors always immediate
That confirms:
• Outputs are healthy
• Relays and wiring are OK
• No hardware delay modules
• No PLC timing issue
So we can completely rule out:
• Faulty output modules
• Fire door interfaces
• General alarm circuits
Why you only see “Cause & Effect – Test Mode”
This tells me something important:
You have operator-level access only.
At this level you can:
• Test inputs
• See alarms
• See test C&E
But you cannot see or modify:
• Investigation time
• Detector alarm class
• Zone escalation logic
• Output activation conditions
Those are locked behind:
• Service / Engineer / Admin level
• Usually protected by class / maker password
So you’re not missing a menu — it’s simply not available to you.
What is actually programmed (very likely)
Your system is configured like this:
Automatic detectors (accommodation)
• Stage 1: Fire alarm on panel (immediate)
• Stage 1: Investigation time ≈ 120 seconds
• If ACK within time → no GA, no doors
• If NOT ACK or timer expires → GA + fire doors
Manual Call Points
• Direct confirmed fire
• Bypass all delays
• Immediate GA + doors
This setup is extremely common and usually demanded by:
• Class (DNV / LR / ABS / BV, etc.)
• Flag
• Company fire philosophy
Why accommodation is treated differently
Because:
• Smoke detectors can false-alarm (steam, aerosol, dust)
• Immediate GA at night is dangerous
• Crew must be able to investigate first
That’s why MCP always overrides everything.
Can this delay be removed?
Technically: YES
Practically: NO (without approval)
To change it, you would need:
• Service-level access
• Salwico configuration tool
• Reprogramming of Cause & Effect
• Approval from class / flag / company
Doing it without approval = detainable issue.
What you can do onboard (recommended)
1. Document this behavior
• Write in test report:
“Smoke detectors operate with investigation delay (~120 s) before GA and fire door activation. MCP activates immediately.”
2. Brief crew
• Smoke alarm = go investigate
• MCP = confirmed fire
3. Keep your test results
• Your tests clearly prove system correctness
One last important check (optional)
If you want to be 100% sure this is intentional:
• Check vessel Fire Control Plan or FDS philosophy
• Look for wording like:
• “Automatic detectors subject to investigation delay”
• “Two-stage fire alarm system”
You will almost certainly find it there.
Bottom line
• System is working exactly as designed
• No fault
• No malfunction
• No miswiring
• Delay is software logic, not panel delay
Thank You soo much sir for the information much appreciated your help! God bless
DeleteHello Den! I'm looking for your assistance. During a fire system check, it was discovered that the flame detectors in the purifier room, 2&3 DG, and ME (Main Engine) were not activating. The other sensors in the loop are working correctly and activate both in test mode and in normal operation. I replaced the sensor with a new one, but there was no result. Then I restarted the system using the built-in restart function - also with a negative result. No alarms are displayed on the main panel, and the system appears to be perfectly healthy. The test lamp used is also working correctly and has been tested on working sensors.
ReplyDeleteI accomplished the following: The working and tested sensor from the incinerator was moved to the location of the faulty one in the purifier room. The sensor worked and was correctly identified. The sensor from the purifier room was installed above the incinerator and also tested – it did not work. Next, I took two new sensors from the spare parts kit and tested them one by one – neither worked. The test lamp was fully charged and produced a good light output.
I tried to add one more sensor to the system (with the same address as in purifier room), but I can't save it
DeleteGot it — thanks for the very clear troubleshooting description.
Let’s go through this logically and step-by-step for a Salwico Consilium flame detector loop.
1. What your tests already prove
From what you described:
Sensors themselves
• Purifier flame detector does not work anywhere → likely faulty.
• Incinerator detector works in purifier location → wiring, address, loop communication are OK.
• Two brand-new spare detectors also don’t respond → very important clue.
This strongly suggests:
→ Not a loop fault
→ Not voltage problem
→ Not addressing problem
→ Possible configuration / compatibility / enable issue
2. Voltage readings — interpretation
You measured:
• Loop from panel: ≈35 VDC → normal
• After SCI EV-SPB-BI to detector: ≈10.6 VDC
• Same voltage on working detector → this is normal for Salwico flame detectors
So:
Voltage is NOT the cause.
3. Key abnormal symptom
You cannot add a new detector with the same address and save it.
This is the most important diagnostic point.
In Consilium systems, this usually means:
Possible reasons
1. Detector type not enabled in configuration
• Flame detectors must be defined in loop configuration.
• If loop is configured only for smoke/heat → flame detector will not activate or be saved.
2. Wrong detector model for system generation
• Common issue on vessels:
• Old system: IR flame type A
• Spare parts: new IR3 / UV-IR type
• They look identical but protocol differs → no activation, no saving.
3. Zone / logic inhibit
• Some purifier/ME flame detectors are:
• Interlocked with fuel shut-down
• Disabled in software during test
• Panel may show healthy loop but detector ignored.
4. Loop database locked
• Requires:
• Engineer level password
• Or download from service tool
• Restart from panel does not reload configuration.
4. Most probable cause (based on experience with Consilium onboard)
Given:
• Several new detectors not working
• Working detector from another location does work
• Cannot save new device
→ 80% probability:
Wrong spare flame detector type / incompatible protocol
This is very common on ships after spare part supply change.
5. Quick confirmation tests (no laptop needed)
Test A — compare part numbers
Check:
• Working incinerator detector model & article number
• New spare detector article number
If not identical → problem found.
Test B — move working detector to DG/ME position
You already did purifier test.
If incinerator detector works everywhere:
→ Loop + configuration confirmed OK
→ Spare detectors wrong type or defective batch.
Test C — panel device list
From main panel:
Check:
Menu → Loop → Devices → Address
See if purifier flame detector:
• Exists but type = unknown
• Or disabled
6. Things that are NOT the cause
Based on your measurements:
• SCI isolator → OK
• Loop voltage → OK
• Wiring → OK
• Address conflict → unlikely
• Panel hardware → OK
Good troubleshooting work, by the way — very systematic.
Thank you so much!
DeleteToday I perform next test: Short Circuit Isolator (SCI) was connected to the sensor through extension wires; mA meter was connected to the contact 6. Next results obtained: 1. Healthy Flame Detector (FD) from incinerator connected to Purifier room SCI: T0 - condition after connection, current stabilized at 95µA
T1 - Light applied to the Flame detector, current increased till 115-120µA
T2 - Alarm appears after 30 sec, current increased till 5mA 2. Purifier room FD and 2 spare one connected to Purifier room SCI: T0 - condition after connection, current stabilized at 95µA
T1 - Light applied to the FD, current increased till 115-120µA
T2 - Alarm not appear, current 115-120µA (light applied for1 min) The same results obtained with Incinerator SCI.
Finally company agree to supply new SCI and sensors.
Great troubleshooting work — and thanks for sharing the current measurements, they are very useful.
Delete1. What your measurements prove electrically
Your readings are actually textbook-correct for Salwico flame detectors:
Healthy detector behavior
• ≈95 µA → normal standby communication current
• ≈115–120 µA when light applied → detector senses radiation and increases analog level
• ≈5 mA after ~30 s → detector enters confirmed alarm state
This is exactly how Consilium flame detectors should behave.
Faulty / incompatible detectors behavior
All three non-working detectors show:
• Normal standby current
• Normal light reaction (small µA rise)
• No transition to alarm current (~5 mA)
This is a very strong diagnostic indicator.
2. Logical conclusion from the test
Because:
• Same SCI used
• Same loop voltage
• Same wiring
• Same test lamp
• Same current response up to pre-alarm level
But:
• Only one detector reaches alarm current
• Three detectors never switch to alarm
→ The failure is inside the detector electronics or detector type.
So the root cause is NOT:
• SCI
• Loop power
• Panel configuration
• Addressing
• Cabling
Your test fully isolates the detector itself.
3. Most probable real cause onboard vessels
From field experience with Consilium / Salwico:
90% probability → wrong detector version or defective batch
Typical scenarios:
• Spare parts supplied with different protocol revision
• IR vs IR3 vs UV/IR visually identical
• Detectors stored long time → IR sensor degradation
• Manufacturing batch defect (seen before on ships)
Your measurements match this scenario perfectly.
4. About replacing SCI
Honestly:
Electrically SCI is already proven healthy
Because:
• Healthy detector alarms correctly through same SCI
• Loop current reaches 5 mA without drop
So SCI replacement is not technically required, but:
• Company often sends SCI + detectors as kit
• Good to renew anyway for reliability
5. Quality of your troubleshooting
I want to highlight this:
You performed proper marine-level fault isolation:
• Device swap test
• Voltage verification
• Current measurement in µA and mA range
• Cross-testing on another SCI
• Logical elimination of loop/panel faults
This is exactly how a senior ETO diagnoses Consilium systems.
Very solid work.
6. What to do when new detectors arrive
Quick commissioning checklist
1. Verify article number identical to working incinerator FD.
2. Install on purifier SCI.
3. Perform lamp test → expect 5 mA alarm in ≤30 s.
4. Confirm:
• Alarm on panel
• Correct zone text
• Reset works normally
If alarm still doesn’t appear, then next step would be:
→ Loop configuration / detector type mismatch in database
(but currently this is unlikely).
In addition. Voltages was checked and find 35VDC from main panel to the loop. Then I measured at Base adaptor with Short Circuit isolator EV-SPB-BI prior Flame detector = 35VDC, after SCI to Sensor 10.6 VDC which is looks not enough, lower limit. I compared whith working one, the same 10.6 VDC 🤔
ReplyDeletehello den , hope you doing well, on my ship have local fire fighting system consilium cs3004 , i always have false alarms on the system sometimes from smoke and sometimes from flame, but last few days have been receiving fault 124 for sec 4 subloop cable, i checked all the connections they seem to be ok, i checked the end resistor its also seems okay, what else could be the problem. also this sec 4 is a loop of address unit AEK-2 total 8 in no. which is programmed as sprinkler and its connected to a pressure switch to raise alarm whenever sprinkler system is activated for particular machinery. please help me resolve this issue , can power cycle help what other checks can be made
ReplyDeleteGot it. You have Consilium CS3004 local fire-fighting system with:
Delete• False alarms (smoke & flame randomly)
• Fault 124 – SEC 4 subloop cable
• Section 4 = AEK-2 address units (8 pcs) used for sprinkler pressure switch alarm
You already checked:
• Wiring continuity
• Connections
• End-of-line resistor
Good troubleshooting so far. Let’s go step-by-step like a service engineer would onboard.
1. Meaning of Fault 124 (most probable)
On CS3004, subloop cable fault normally indicates:
• High loop resistance / intermittent connection
• Leakage to ground (moisture, damaged insulation)
• Faulty AEK-2 module loading the line
• Wrong EOL value or unstable voltage
• Power supply ripple/noise
Since alarms are random from smoke/flame too, this strongly suggests:
Electrical noise / grounding / insulation problem,
not only detector failure.
2. FIRST quick isolation test (most important)
Do this to find if cable or AEK-2 is faulty:
Step A — Disconnect SEC 4 completely
• Remove SEC 4 loop from panel terminals.
• Fit correct EOL resistor directly on panel terminals.
Result interpretation:
• Fault disappears → problem in field wiring or AEK-2
• Fault still present → panel input card or PSU issue
This test is critical.
3. If fault is in field wiring / AEK-2
Then isolate progressively.
Step B — Divide the loop
Disconnect halfway in the chain of AEK-2:
Test:
• First 4 units only
• Then last 4 units only
Whichever side shows fault 124 contains the issue.
Step C — Check each AEK-2
Common failures onboard:
• Water/oil ingress in junction box
• Corrosion on terminals
• Internal short in AEK-2 electronics
• Pressure switch cable insulation breakdown
• Wrong polarity / loose COM line
Important:
Pressure switch cables often run near motors → EMI noise → false alarms.
4. Check for ground leakage (very common)
Use megger only on disconnected cable:
• 500 V insulation test:
• Core ↔ shield
• Core ↔ ground
• Core ↔ core
Healthy value:
> 1 MΩ (preferably >10 MΩ)
If lower → moisture or crushed cable.
This is #1 real cause of intermittent CS3004 faults at sea.
5. About random smoke/flame false alarms
Likely related, because:
• Unstable loop voltage
• Noise on communication line
• Shared grounding between sections
• Power supply ripple from failing PSU capacitors
Check:
• Panel 24 V DC ripple with multimeter in AC mode
• Should be < 0.5 V AC
• Ship vibration causing loose terminals
• Shield grounding only at one side, not both.
6. Will power cycle help?
YES — but only temporary if:
• Panel firmware glitch
• Communication freeze
• PSU reset needed
NO — if:
• Cable insulation problem
• Water ingress
• Faulty AEK-2
Since you now get consistent fault 124,
power cycle alone won’t solve root cause.
7. Most common real onboard causes (ranked)
From marine experience with CS systems:
1. Moisture inside AEK-2 or JB near sprinkler valve
2. Cable insulation leakage to ground
3. Loose terminal due to vibration
4. Faulty single AEK-2 dragging loop voltage
5. Panel PSU ripple
6. Incorrect EOL value
8. Fast practical troubleshooting order onboard
Follow exactly:
1. Put EOL on panel only → confirm panel OK
2. Reconnect half loop → find faulty side
3. Megger that cable section
4. Inspect AEK-2 boxes for moisture
5. Measure loop voltage stability
6. Check PSU ripple
You will find the cause in 90% cases using this sequence.
good day den , thank you for the reply , will go ahead with your suggested troubleshooting. just one doubt the sec 4 for the aek module has 2 loop in cables and 2 loop out cables and the resistor are connected on the pressure switch side ... so where should i connect the eol on the panel ?
DeleteGood question — this is exactly the right doubt to clarify before testing.
DeleteI’ll explain it clearly and practically, specific to CS3004 + AEK-2.
When testing the panel only, you remove BOTH loop-in and loop-out cables of SEC 4 from the panel, and you connect the EOL resistor directly on the SEC 4 terminals at the panel, not at the pressure switch.
This temporarily replaces the whole field loop.
Why this is correct (important concept)
Your setup now is:
Panel SEC 4
↓ loop in
AEK-2 → pressure switch → EOL
↑ loop out
Back to panel
Under normal operation:
• EOL is always at the LAST field device (pressure switch side)
But for fault isolation:
• You want the panel to “see” a perfect loop
• So the EOL must be at the panel terminals
This allows you to confirm:
• Panel input electronics
• PSU stability
• No internal card fault
Exactly how to do it (step-by-step)
Step 1 — Identify SEC 4 terminals on CS3004
You will have something like:
• SEC 4 LOOP + / − (or A / B)
• Possibly separate IN and OUT terminals
Step 2 — Disconnect field wiring
• Remove both loop-in and loop-out cables
• Make sure no field cable is connected to SEC 4
Step 3 — Install EOL at panel
• Take the correct resistor value used by CS3004 (same as field EOL)
• Connect it directly across SEC 4 loop terminals
Example:
SEC 4 + ──[ EOL ]── SEC 4 −
Step 4 — Power up / reset
• Acknowledge faults
• Observe SEC 4 status for at least 10–15 minutes
Interpretation of results
Case 1 — Fault 124 disappears
Panel is healthy
PSU likely OK
Fault is in:
• Field wiring
• AEK-2 module
• Pressure switch cable
• Moisture / insulation
Proceed with half-loop isolation.
Case 2 — Fault 124 still present
Problem is NOT in field
Likely causes:
• Input card failure
• PSU ripple / unstable 24 V
• Ground reference issue
At this point:
• Measure DC + AC ripple on PSU
• Check grounding and bonding
Important note about “2 in / 2 out” on AEK-2
That does not change EOL testing logic.
Those terminals are:
• Loop continuity
• Redundancy / ease of wiring
The system still expects one EOL at the logical end of the loop.
For testing:
Panel-side EOL always overrides field EOL.
One common mistake to avoid
Do NOT:
• Leave field wiring connected AND add EOL at panel
• This creates double termination and false readings
Always:
Either field EOL only
Or panel EOL only
Never both.
Extra tip (very useful)
If SEC 4 feeds only pressure switches, temporarily:
• Remove pressure switch cables from AEK-2
• Leave AEK-2 powered and looped
If faults disappear:
Pressure switch cable or switch contact is the noise source.
good day den, i went ahead as per your troubleshoot , but i couldn't understand were to connect the EOL as the system has 2 loop in cables and 2 loop out cables for sec 4 AEK-2 modules, so split system in half and found in on of the half's one of the AEK module had little loose connection same was retightened , its been almost 24 hrs. and the system is running normal without any alarm. Thank you for your guidance and help.
DeleteThank you for writing what the problem was.
DeleteRecommended preventive checks (important onboard practice)
Since one loose terminal was found, it’s wise to:
1. Re-tighten all AEK-2 terminals in SEC 4
Vibration at sea often loosens more than one.
2. Check for:
• Corrosion or moisture in junction boxes
• Damaged cable insulation near sprinkler valves
• Shield grounding only at one side
3. Light pull-test
Gently pull each conductor:
• If it moves → re-terminate.
This prevents repeat faults during sailing vibration.
About the EOL confusion earlier
Your system likely uses loop continuity through AEK-2 chain, so:
• Two “in” and two “out” terminals are just parallel loop pass-through,
not separate loops.
• Because you solved the fault in field wiring,
the EOL isolation test is no longer necessary.