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!
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
Delete