News:

  • November 08, 2025, 06:50:57 AM

Login with username, password and session length

Recent Posts

Pages: [1] 2 3 ... 10
1
Do-more CPUs and Do-more Designer Software / Re: BX-DMIO Error Slot 255
« Last post by BobO on Today at 12:51:01 AM »
So the customer replaced the BX-DMIO and it is still showing an error light on the DMIO and when I log into the BRX PLC I see the same Slot 255 error. 

So at this point I guess the BRX Master is the bad component here, just very misleading as the error points toward the DMIO device?

Slot 255 actually points to the onboard I/O, which there isn't any. It isn't a hardware problem, it's probably garbage in the config. I've been out on vacation, but I'll look into it when I'm back in the office.
2
Do-more CPUs and Do-more Designer Software / Re: BX-DMIO Error Slot 255
« Last post by JeffS on November 07, 2025, 12:43:51 PM »
So the customer replaced the BX-DMIO and it is still showing an error light on the DMIO and when I log into the BRX PLC I see the same Slot 255 error. 

So at this point I guess the BRX Master is the bad component here, just very misleading as the error points toward the DMIO device?
3
Do-more CPUs and Do-more Designer Software / BX-DMIO Error Slot 255
« Last post by JeffS on November 06, 2025, 04:38:47 PM »
I have a remote IO module reporting a configuration mismatch on Slot 255.  I tried re-writing booter/firmware, reset defaults, rewrote booter/firmware to the BRX Master with no luck.  I am assuming this remote IO module is dead, but wanted to report the odd message.
4
Do-more CPUs and Do-more Designer Software / Re: MODBUS TCP with H2-D1ME CPU
« Last post by franji1 on November 05, 2025, 05:24:26 PM »
Instead of using R as your setpoint, use casts of Modbus 16 bit Holding Register block (MHR).  Two gotchas in Do-more is that REAL casts of a memory location must be aligned on DWORD boundaries (so even MHR addresses), and the 2nd gotcha is there is no Modbus address 0 (everything starts at offset 1 with Modbus, e.g. Modbus Holding Register 40001 maps to MHR1, so you can't use MHR0, but you can use MHR2 or MHR10 for the cast).

To help out, let's use Nicknames.  Instead of assigning the Nickname MySetpoint to R0, assign it to MHR10:RD (the : is a "cast operator"), which means look at Holding Register 40010 and 40011 (MHR10 and MHR11) as a DWORD REAL.

To learn about casts, there's a video that helps with that:
https://www.youtube.com/watch?v=BvTuz6H3sD4

The easiest way to assign a nickname to a cast is from within the Doc Editor (Ctrl+D), hit the Add button and enter MHR10:RD in the Element field (see screen shot).

Then just use and enter MySetpoint in your logic, data view, trend view, everywhere (or enter MHR10:RD).  The Auto-Complete should make entering the Nickname easy.

The behavior for the relay is simpler, just use MC (Modbus Coil) instead of a C bit for everything that is read/write via Modbus.  No casts needed for bit memory (bit is a bit).

The purpose of these reserved memory areas is to protect the memory locations that are NOT accessible via Modbus.  In a 260, ANYTHING can write to I/O since EVERYTHING is mapped to Modbus memory (you just need that spreadsheet).  In Do-more, ONLY put the Modbus accessible data in your MHR, MIR, MC, MI data blocks.  Nothing else is accessible via Modbus (not X, not Y).

There are similar blocks for legacy DirectLOGIC data types: DLX, DLY, DLC, DLV that are octal.  So a 260 could read/write using RX/WX to Do-more to those memory blocks.  There is also DLRX, DLWX instructions for Do-more program performing the legacy DL protocol to those legacy PLCs.  Similar reasoning for the DL blocks as for the Modbus blocks.
5
Do-more CPUs and Do-more Designer Software / MODBUS TCP with H2-D1ME CPU
« Last post by jktucker92 on November 05, 2025, 04:00:44 PM »
I am working with the Do-More PLC's for the first time and have a question about using Modbus TCP with these PLC's.  For the old DL260 CPU, Modbus was straight-forward and a PLC memory address could be read and written to after you used the excel spreadsheet to map a PLC address to a Modbus holding register.  For the H2-D1ME CPU, what I'm reading is the only memory addresses available via Modbus TCP are the MHR, MIR, MC and MI addresses.  I use Ignition to interface with my PLC's, and I want Ignition to be able to read a setpoint from the PLC memory and be able to change that setpoint.  I don't see how I can do this.  For example, the setpoint is a real number, say R0, while I can copy that memory to the MHR address space to read via Modbus, I can't change that value in Ignition.
What am I missing?  Is there another way to handle this.  I also want to be able to read the position of a relay that controls a valve and also operate that valve.  I have some concepts using multiple values to read and write these values, but that gets very complicated.  Is there a way to mirror the R address space to the MHR address space for read-write capability?  Is there another method I should be using to connect Ignition to these PLCs?
6
The cal factor is actually 78.22385, the rest has to be rounding errors. The issue in rung 3&4 actually starts when the Total Pulse value reaches 1,073,741,823, which is exactly half the max value of a Dword, which means it has something to do with the final bit in the dword. My workaround is to clear all values to 0 when they reach 1 billion.
7
What I find odd is that if you take the value of MeterTotalPulse0, which is 1095958347, and divide that by your cal factor of 78.11 you should get 14030961 and not 14010541 which is the result shown in rung 4. In order to get the answer that you did, the CalFactorMater0 term would have to be 78.223842.

And then assuming the value for your MeterPulseRate0 in rung 2 is the freqcnt value from rung 1 (6309.48), I see that the result of 80.659 shown doesn't quite match up with a cal factor of 78.11 but in this case would be 78.2241287. Which raises the question, why is the value for CalFactorMater0 slightly different between rungs 2 and 4???

Is your cal factor term changing dynamically?
8
The task is running continueosly, but I've figured out what the issue is. When I cleared  MeterTotalPulses0 to zero, the issue resolved instantly. After follow up troubleshooting I've determined that when MeterTotalPulses0  register  increments greater than 1.06 billion, that is when the issue starts with the math instruction in rung 4, not calculating every scan. Are the D registers useful right up to their max of 2.1 billion?
9
Do-more CPUs and Do-more Designer Software / Re: Delta contact not performing as expected.
« Last post by BobO on November 03, 2025, 03:21:54 PM »
I think the issue is that rung number 4 is only calculating once per second rather than every scan. Shouldn't the alwayson bit be triggering a calculation every scan?

That math box will solve every scan. If this is only happening once per second, it is more likely that your task isn't running continuously.
10
 I think the issue is that rung number 4 is only calculating once per second rather than every scan. Shouldn't the alwayson bit be triggering a calculation every scan?
Pages: [1] 2 3 ... 10