Recent Posts

1

Do-more CPUs and Do-more Designer Software / Re: Pasting or editing subroutines doesn't set the 'dirty' flag

« Last post by franji1 on October 09, 2026, 09:25:58 AM »

minor issue. After pasting a subroutine from one do-more project to another, the 'save' function remains disabled. Adding a comment in the newly-pasted function doesn't hep, nor does editing the ladder. You need make a change to the main program ladder to re-enable 'save'.
Presumably this also has implications for undoing

I tried pasting a subroutine from one project into another using 2.11.2 and the SAVE TO DISK became enabled, as expected.  I also then tried editing a rung comment, and SAVE TO DISK became enabled, as expected.

Not sure what is going on with your issue.  Is your %temp% folder environment variable pointing to a normal local user-specific folder (or is it on a network, IT in some places keep everything "in the cloud").

Also, try it on a newly created disk project and see if you the same behavior for PASTE CODE BLOCK and COMMENT EDIT.

2

Do-more CPUs and Do-more Designer Software / Pasting or editing subroutines doesn't set the 'dirty' flag

« Last post by effgee on October 09, 2026, 08:50:07 AM »

minor issue. After pasting a subroutine from one do-more project to another, the 'save' function remains disabled. Adding a comment in the newly-pasted function doesn't hep, nor does editing the ladder. You need make a change to the main program ladder to re-enable 'save'.
Presumably this also has implications for undoing

3

Do-more CPUs and Do-more Designer Software / Re: Multiple Cmores turning off and on a pump using Do-more

« Last post by brucek on September 14, 2026, 08:38:48 AM »

The panels just read and write to what you tell it to in the plc so just do the same thing on all 3 screens and your all set. you can make it a start/stop or toggle on and off what ever you want and indicate if its running or not.

4

Do-more CPUs and Do-more Designer Software / Re: Stage Program retaining the current stage after power cycle?

« Last post by Mike Nash on September 11, 2026, 05:26:47 PM »

I added the INC in each stage of two programs.
I get 2 increments each time S0 is called on either program.

I have also bounced back and forth between setting the axes as retentive in the heaps and have decided I can't tell.

Currently I suspect I may not be handling the startup from power cycle well. I'll dig in further later.

Right now it is working again without miss.

5

Do-more CPUs and Do-more Designer Software / Re: Stage Program retaining the current stage after power cycle?

« Last post by franji1 on September 11, 2026, 04:12:03 PM »

AI found the DirectLOGIC "Stage" memory, which is S memory.  Do-more has "local" stage bits inside each and every PROGRAM code block (128 of them).

Not sure exactly your transition logic in S0, but sticking an INC D99 (where D99 is retentive) at the top of S0 (right under SG S0 w/no input logic) would tell you if S0 ran at all (e.g. it goes from 4 to 5 after a power cycle).

6

Do-more CPUs and Do-more Designer Software / Re: Stage Program retaining the current stage after power cycle?

« Last post by Mike Nash on September 11, 2026, 03:59:09 PM »

Thanks Franji,

It doesn't appear to ever bother going to S0 after power cycle since everything to do with that axis stays at not-configured. It jumps straight to S1 like it never stopped, except it's no longer configured.

So after I posted I went to Google Search and its "AI" said I needed to go to Memory Configuration and check that the "S" ranges weren't retentive. Doh! What S ranges? Told it they didn't exist. It excused itself and said to check the program properties, which I had (and yes I had already unticked the retentive program structure and saved.) Anyway, I then set  $HSIO_001_Axis1 to No under Heap Items Retentive. And now it behaves.

I don't understand that as all the Axis and CT structures are retentive by default.

And yes the RUN instruction for that Program (in $Main) has a conditional that is false until after $Main is running.

I have another almost identically configured axis on the same HSIO2 that doesn't get hung up. It's still set retentive.

I'll dig around further if it crops back up. But honestly, that particular axis won't be staying after development. But there are three more that will, and I don't need weirdness.

7

Do-more CPUs and Do-more Designer Software / Re: Stage Program retaining the current stage after power cycle?

« Last post by franji1 on September 11, 2026, 03:28:10 PM »

I just tried it.  My program stays in S0.  I am guessing that after power up, S0's AXCCONFIG executes and completes immediately and jumps to S1 (AXCONFIG OnSuccess JMP S1?)

Make sure NOTHING is driving your AXCONFIG so it stays in S0.

Also, another possibility, make sure what is doing the RUN to your program does NOT run it if you don't what the program running at all after power-up (not sure if this is the desired behavior or not).

8

Do-more CPUs and Do-more Designer Software / Stage Program retaining the current stage after power cycle?

« Last post by Mike Nash on September 11, 2026, 12:53:59 PM »

Brand new BX-DM1E with 2 HSIO2 cards.
v2.11.2 software and firmware.

I am using a conditioned RUN command in $Main to start a stage program.

If the stage program is running and I switch to program mode and back to run, the stage program will not execute until the rung is enabled in $Main. This is the expected behavior.

If I cycle power while the stage program is running, it comes back on with the stage program still executing at the stage it was in when it lost power. This means in my case that it skips Stage S0 where my AXCONFIG resides and both it and the AXVEL in Stage S1 shows execution mode as not-configured (Mode 0). The help files say it is "unconfigured".

Oddly, if I have a contact in the AXVEL rung that is false and then goes true after the PLC is running, it will switch mode straight to smart-velocity.

This starting with the stage program running and already in S1 is undesirable. I thought it might be that I had set the stage program to retentive. But unticking the box didn't change the results and yes it was a program mode change to install.

How do I prevent this?

Second question - This is being used at the moment to simulate a lead encoder going out of HSIO2 Axis1, jumped into HSIO2 CT2. I am trying to simulate the retentive accumulator that will be going into HSIO2 CT1. CT1 is lead, CT2 is follow.

I need to maintain the Current Position from Axis1 through a power loss/restore and get it back into Axis1. While this part goes away after testing, it is not cooperating.

Currently I have:

STR C100 AXVEL "blah blah blah"
AND $HSIO_001_Axis1.Active
MOVE $HSIO_001_Axis1.CurrentPosition D100

It does work, but does grab the D100 value before the CurrentPosition end value every time.
I tried saving values in $tLastScan, but it never reads the real CurrentPosition on power loss, so it's always zero.

Is there a better way?

9

Do-more CPUs and Do-more Designer Software / Re: Peerlink Update rate

« Last post by BobO on September 09, 2026, 09:26:39 PM »

Is there any way to increase the peerlink update rate from 100ms?

Sorry, no.

10

Do-more CPUs and Do-more Designer Software / Peerlink Update rate

« Last post by LennyG on September 09, 2026, 05:40:41 PM »

Is there any way to increase the peerlink update rate from 100ms?