Created Date: January 08,2015

Created by: plcnut

If it was me, then I would switch to DoMore.

If you are stuck with the 06, then your only options (that I am aware of) to organize are:

1) Use subroutines as you mentioned. (I have never used subroutines with a DL)

2) Use Stages. This is NOT what Stage programming is intended for, but it is about the only way I know to break up a program in a DL for readability as well as reducing scan time. Before going with Stage, be sure to read the manual; it can save you a lot of headaches down the road.

Created Date: January 08,2015

Created by: Cap

I just took a look at what I think is my largest program running in an '06.. it's 200 line numbers..

Mostly what is sitting in my '06's Started out in a 260 running something large.. then I took pieces out as Modules, placed them into the '06's .. and then tailored them to run in that new Hardware environment..

I group into Subroutines.. MOST of the Subroutines run all the time.. But it gets the 'Overhead ' out of the 'Valuable real estate ' located above the END Statement..

Like.. My K1010 Subroutine is the Analog input conversion Sub.. It has 7 Data Tables set in V Mem that it works from

1) Sensor Start Reading

2)Sensor Range

3)Calibration Offset

4)Low Range Error Reading

5)Hi Range Error Reading

6)Sensor Real Output table

7)BCD Output Table

It also has One Timer for each Input, that allows the range to be excedded for 1 second before setting the Channel Error C bit ( One bit for each Channel ).. and it also has A Channel Active Flag.. it you want the error checking to function, set the flag for that channel..

Different 'Versions ' of my 1010 routine will work either 8/16/32/48 inputs.. but it sits at K1010..

My K100 Routine is my 'time Base '.. it takes care of C 100-c103 that are on for one cycle either 1 second, 1 minute, 1 hour.. so all my programs will use 100-103 for time base keeping..

I assign all of my Inputs from hardware to X inputs like normal.. then Move them to GX locations for the program to actually use.. that is done in SBR K 710

This way I can 'Force On ' ( or off ) inputs from software.. I move all the read inputs from X to GX, close to the first line of the program..

Likewise all of my Outputs are Hardware Y outputs.. ( SBR K700) but the Program has addressed them as GY outputs.. Again, so I can force or Kill outputs ( Hand/Off/Auto ETC ).. that routine is the last line before the End Statement.. and all of the 'twisting ' nessasary to get the Outputs of program to line up with Hardware Outputs is done in SBR k700..

Like Some output requests ( turn on VS Drive ) do not have an actual hardware location.. it's done with Modbus.. BUT if I OUT GY110, it will be trapped by the K700 Routine at the end of the program, and redirect it to the K760 Routine that does the serial communication to the Freq Drives..

I know this is long winded.. Sorry.. but once you get the 'module Concept ' it frees up the programmer and the guy to follow.. even if it is you..

Cap

Created Date: January 08,2015

Created by: DenisOZ

Onging issue with Dsoft

Every program I do in DS, I break the functional areas into stages.

At the start of the program, I set the relevant stages ON, and then use the stage navigator as a bookmark navigator.

I often use a mix of set stages and jump routines as well - just set a contiguous range of stages for the area that do not require jumps.

The main problem with this system, is that you will have to scroll to the mid section of the stage navigator page to get a contiguous stage representation of the stages. Luckily, DS will remember this position on program closeout.

The single biggest failure of DS is the lack of stage or subroutine navigation.

I can put up with the dodgy number systems etc, but I have complained long and hard about this over the years on this forum, to be told by all at ADC and Host that is being addressed.

I realise that Host are putting all their resources into DoMore, and that is commendable, but a decent revision of Dsoft would return money for the vendor, and us who program for a living. (Dsoft is purchased, Dmore is free!! Go figure)

I downloaded DS6 in anticipation of this issue being addressed, and was bitterly disappointed to find that all we have is a 'lipstick on a pig ' approach to this problem.

I am now one of the legion who have gone over to the dark side with a move to AB, Omron, Siemens where at least I do not get push back from the newer crop of integrators that I work with re the terrible visuals of Dsoft

Created Date: January 09,2015

Created by: ControlsGuy

I'm going to chime in with the conventional wisdom and say:

If you can, use Do-More. It's a way better PLC, but then not really in the same niche, so I assume that's not feasible.

Yes, use subroutines. You can do a power up handler subroutine that doesn't run except on SP0, put HMI-related stuff in a subroutine, put anything that doesn't have to be done all the time in a subroutine, etc.

You can even jerry-rig function-like behavior using subroutines. In one app, for example, I was using the HSC in the 06, where all setpoints, current values, etc., have to be in encoder pulses. In DL, you tend to end up with long vertical stacks of boxes in the last column. So in the encoder app, I'd do LDR 6.5 (inches or whatever), followed by a GTS in the same stack. The subroutine just did a conversion starting with whatever was in the accumulator when it was called, so whatever followed the GTS on the calling rung already had the distance in the accumulator in encoder counts without me having to do the conversion explicitly, and plus the conversion was called from numerous places in the program, so doing it that way reduced program bulk, precluded typos when replicating the same logic over and over, and you can change the conversion in one place if it changes.

Created Date: January 09,2015

Created by: ControlsGuy

Agree, DenisOZ. The stage UI is hideous (and also non-standard) compared to most brands implementations of SFC. It's so bad I refuse to use it, although I do like SFC in principle, but there are several critical upgrades that it needs before I could use it without wanting to gouge my eyes out. Host intends to improve it, but their plate is really really full (and I'm talking about them adding it to Do-More; I really don't care if it ever gets upgraded in DL or not).

I mean, Do-More is SO much better a PLC, that once they have an offering the small brick and semi-brick niche, why would you ever use another DL anyway?

Created Date: January 09,2015

Created by: franji1

The simplest/crudest hasn't been mentioned yet, but it is something I use a lot to make it easier to scan through the logic, BLANK LINES. It is acceptible to leave blank rungs with the (NOP) at the end. I leave a few blank rungs between different sections of the program so they stand out easily when scrolling through.

I have done this, then put a large block comment on the NOP rung describing this "section " of code. I 've even had to use 2 NOP rungs when my large block comment exceeded 16 lines (the limit of a single rung comment).

However, NAVIGATION of the program is still EXTREMELY DIFFICULT with a large monolithic program. This is where Do-more code-blocks really shine. The Project Browser view has a tree that shows all the code-blocks. Just double click on a code-block, and it opens up its Ladder View. Below the code-block tree node are the individual rungs and stages within THAT code-block. Each rung/stage in the tree also shows the first line of the rung comment for THAT rung/stage, helping provide context while navigating. Just double click on any rung or stage to open the Ladder View to THAT SPECIFIC RUNG or STAGE. It's nice!

See the attached screen shot showing an example Project Browser where I am looking at one of the rungs in the "MonitorAlarms " code-block.

Created Date: January 08,2015

Created by: JimEb

In the midst of writing a directsoft program for a DL06 that's turning into a jumbled mess of a beast.

I'm up to about 70 rungs just configuring I/O's and variables and I haven't even started writing the functioning part of the program. Any tips/hints/tricks to writing and organizing a large program?

I'm using lots of comments, but it would be nice you could do something like draw a block around a group of rungs. Or subroutines that run concurrent to the main program for number crunching, etc.