Recent Posts

41

ECOMs and ECOM100s / Re: ECOM100 blocking the bus

« Last post by Angelo on May 08, 2026, 07:39:42 PM »

Ah.... ok.

But do you think the problem is the Altera chip, even with the multimeter showing a short between pin 3 and the GND pin on the LJ245 IC?

42

ECOMs and ECOM100s / Re: ECOM100 blocking the bus

« Last post by franji1 on May 08, 2026, 08:36:04 AM »

The Altera part

43

ECOMs and ECOM100s / Re: ECOM100 blocking the bus

« Last post by Angelo on May 07, 2026, 09:45:31 PM »

That's an FPGA, which is not field replaceable (it must also be programmed).

Contact support at hosteng.com about RMA

What ? The LJ245A ?

44

ECOMs and ECOM100s / Re: ECOM100 blocking the bus

« Last post by franji1 on May 07, 2026, 07:45:44 AM »

That's an FPGA, which is not field replaceable (it must also be programmed).

Contact support at hosteng.com about RMA

45

ECOMs and ECOM100s / Re: ECOM100 blocking the bus

« Last post by Angelo on May 06, 2026, 10:38:28 PM »

I have checked. All pins are perfect aligned.

The system was running fine for the last 8 years, nobody removed the ECOM100 from the bus since then. So the bent pins hypothesis  would have 0% to be the case.


I forgot to ulpload the photo.

46

ECOMs and ECOM100s / Re: ECOM100 blocking the bus

« Last post by franji1 on May 06, 2026, 12:07:20 PM »

It may be a bent connector pin.  405 modules have that issue since they are rotated/levered into position and the connector sometimes doesn't line up perfectly and ends up bending pin(s).

47

ECOMs and ECOM100s / Re: ECOM100 blocking the bus

« Last post by Angelo on May 06, 2026, 12:01:06 PM »

Just removed the board to make some measurements with voltimeter.

What I´ve found:

 the IC (U13) which is a LJ245A, see photo below, there is a short between ping 13 (GND) to pin 3 (A1).

See that the U15 and U14 are also the same LJ245A

The LJ245A is the marking of Texas Intrument SN74LVC4245A. This CI is Octal Bus Transceiver and 3.3-V to 5-V Shifter
With 3-State Outputs.

Using ChatGPT I got a response like this:


"9. Definitive Test

The best method is to:

remove the IC,
test whether the bus communication returns,
or replace it directly.

Since you already work with PLCs and industrial buses:

if removing the IC causes the system to “come back to life” or restores communication,
then the IC is most likely internally locking up the bus.

This is extremely common."


Which seems to be the case as it cites  "lockin up the bus"


I will try to find the IC to purchase and then replace it.
 

48

Do-more CPUs and Do-more Designer Software / Re: Need lower scan time for a couple rungs

« Last post by franji1 on May 06, 2026, 10:50:00 AM »

So an interrupt code block would not work in this instance?

So sorry I never responded.  Analog does not support any kind of HSIO functionality (interrupts fall in this category).  Even though you could technically look at the analog values in a timed 1ms ISR, the image register values would not actually be updated except for the normal PLC Logic I/O scan (every 5 ms).

In this situation, the only way to get 1ms update on your analog is to get your PLC scan to be around 1ms.

Since there is no HSIO Analog module, you could "create your own" by doing it with another BRX -M (or MPU with onboard analog?) doing JUST the high speed analog I/O processing (3 rungs, nothing else or very little else).  Of course, this is only useful if your "high speed analog processing" does something with it, and we may just be kicking the problem "down the road".

Based on what you need to do with this high speed analog information, that would dictate whether moving the analog prcessing to a separate MPU even makes sense.

If you are logging information to a file, the RAM drive is much faster than SD card (if that's part of your "processing").  If so, this is definitely do-able. 

However, even in a separate PLC, scan time is still critical for the 1ms processing.

49

ECOMs and ECOM100s / ECOM100 blocking the bus

« Last post by Angelo on May 06, 2026, 10:35:20 AM »

Dear all,

I have an H4-ECOM100 module, and it appears to be causing a problem in my system. When this module is installed together with the other modules, the D4-450 CPU cannot communicate with any module on the bus. However, when I remove the H4-ECOM100 module from the bus, everything returns to normal.

Therefore, I concluded that something is wrong with the H4-ECOM100 module.

Could someone please help me?

Best regards,
Angelo

50

Do-more CPUs and Do-more Designer Software / Re: Bug Repot: Cannot copy paste tasks or import from text file possible, need help

« Last post by franji1 on May 06, 2026, 09:21:21 AM »

Ladder Paste does not support TEXT FORMAT EXPLICITLY.  The Ladder CUT/COPY Clipboard stores the contents in multiple formats, one of which is the internal Ladder format that Ladder Paste supports, but it also supports TEXT for pasting into any windows program that supports TEXT (like Notepad, Word, etc.), allowing you to do what you are doing:

• Copy/Cut code from Ladder into the clipboard
• Paste into Notepad
• Edit whatever you need in Notepad and Save
• File->Import that file as a new project or via Tools->Insert Instructions as a code block or as a rung/code (this requires some guidance)

The Paste operation for Ladder View only supports the Ladder format, not plain text (text can be anything).

Yes, versioning currently does require more lifting on your part.  We are looking to implement library functionality, and versioning (not archiving) is one of the features that the library should support.

One alternative work flow would be to keep the old name in the .TXT file, then just delete the code block (but not the heap item), then do the "Insert Instructions from File".  The Heap-Item would not have to be defined in the import .txt file in that case since it already exists.  However, if you do want to have BOTH versions in your project, then you definitely have to do what you described and have 2 different code blocks and 2 different heap items (similarly named, e.g. Name2).  Of course, the corresponding ENTASK(s) would have to be driven properly to enable one TASK vs. the other.