Supporting DL205 and BRX with "single program" issues with @POM and @IntSerial

[RobertW]

I am trying to support a family of applications that were originally created on the DL205 hardware, but later versions have been switched over to using mostly the BRX platform. The previous method of supporting these systems has been to have multiple code lines, one for each major platform. But in an attempt to streamline the code support process we are trying to incorporate the code lines into a single program that can be maintained, built, and distributed to all machines via DMLoader. Even if the final build between the H2 and BRX must be separate files, that is much better than making the same changes across many programs and built for all of them, and distributed based on the specific product to be updated. Logic and IO assignment wise this has not been too much of a problem, but I am running into one hard issue: I have the @IntSerModbusClient on the DL205, and The @POM server on the BRX for using MRX MWX instructions. In the end, that is one of the only things that I cant just make work in a single program that could be built for either PLC as the @POM doesn't exist on the DL205.

The DL205 and BRX PLC use the Modbus for slightly different things, so the logical code for each of those only need to activate depending on which PLC this is installed on, and I can additionally pull the actual MRX and MWX instructions into their own program, so if need be I can just copy/paste that single program into the final project right before build.

I am trying to think down a couple different paths right now:

1) A painfully obvious suggestion that deals with this in a way that I am overlooking.

2) Some method of indirectly referencing the hardware to be used by the PLC that either I can have a single referenced address that is resolved at runtime to get the right device set up and used.

3) Some kind of automated method for inserting code blocks into a program that doesn't necessitate the manual use of the Copy/Paste tool, as I want to avoid errors by a human. One way that seems usable would be to use the import/export functionality create the "Core" project, export it, and then import the code into the "DL205" "BRX" projects to be built. If there are command line capabilities that I could create a script to help do these actions directly from DMD would be ideal. I can also work with Mnemonic files and: Export - run script that adds programs and CALL instructions - Import. Again, command line or automation of any type that could help this process would be wonderful.

If there are any suggestions or methods for doing this that I could use as an example, thank you.

[Controls Guy]

One option, don't use a POM, use the internal serial port in the BRX, then you get @IntSerModbusClient like the 205.

Or, an upgrade from the 205 to an H2-DM1/E seems like a pretty modest expense for the customer to undertake to make this work unless there are thousands out there or something.   With both models as Do-More, the program would be more interchangeable, though there are still some things the BRX can do that the H2 Do-More can't, but it should be much more limited and might not impact you depending on what you're doing.

Yet another option would be to turn your 205 bases into remote I/O with an EBC and all versions of the software run in a BRX.

[RobertW]

Or, an upgrade from the 205 to an H2-DM1/E seems like a pretty modest expense for the customer to undertake to make this work unless there are thousands out there or something

Yet another option would be to turn your 205 bases into remote I/O with an EBC and all versions of the software run in a BRX.

Unfortunately, thousands in the field is the situation I am up against. And your idea is already a planned future endeavor, more or less. About an 18 month span for that to come to full fruition. This is to help support the fielded systems until that version of everything is created. This is basically an undertaking just to free up engineering time moving forward by not having to continue duplication of effort just to put out software changes that are needed.

One option, don't use a POM, use the internal serial port in the BRX, then you get @IntSerModbusClient like the 205.

Unfortunately, that is again something that I am stuck with, I inherited this system. The 205 is connected to a single optional VFD via the serial port, through an RS-485 converter. On the versions that were switched to BRX, the RS-485 POM was utilized to communicate with multiple VFDs that used to be controlled by hard I/O. We don't want to be in the position where we have to demand hardware changes to our customers just to enable small software changes. Thus, a completely software adaptation is the only option.

[Controls Guy]

Unfortunately, thousands in the field is the situation I am up against. And your idea is already a planned future endeavor, more or less. About an 18 month span for that to come to full fruition.

OK, understood.

Unfortunately, that is again something that I am stuck with, I inherited this system. The 205 is connected to a single optional VFD via the serial port, through an RS-485 converter. On the versions that were switched to BRX, the RS-485 POM was utilized to communicate with multiple VFDs that used to be controlled by hard I/O. We don't want to be in the position where we have to demand hardware changes to our customers just to enable small software changes.

But there is 485 on the internal serial port on all BRX, which shows up as @IntSerModbusClient, just like on the 205.   Is there some reason you can't use the internal port on the BRX in lieu of the POM?

[RobertW]

But there is 485 on the internal serial port on all BRX, which shows up as @IntSerModbusClient, just like on the 205.   Is there some reason you can't use the internal port on the BRX in lieu of the POM?

Hmm... I think I need to check in on some of the old engineers for self-inflicted foot injuries. But, this feels like it fits under category 1) A painfully obvious suggestion that deals with this in a way that I am overlooking; as long as I can get the company on board with moving a plug up 2 inches before loading the new software.

Thank you

[Controls Guy]

No no no!  Unplug the serial, and remount the PLC 2" lower!   

[RobertW]

But there is 485 on the internal serial port on all BRX, which shows up as @IntSerModbusClient, just like on the 205.   Is there some reason you can't use the internal port on the BRX in lieu of the POM?

Hmm... I think I need to check in on some of the old engineers for self-inflicted foot injuries. But, this feels like it fits under category 1) A painfully obvious suggestion that deals with this in a way that I am overlooking; as long as I can get the company on board with moving a plug up 2 inches before loading the new software.

Thank you

I found someone with an answer: Long story short, the hole in their foot is there, carefully aimed to miss any vital structures, but I probably need to support both serial ports. Down the copy/paste mnemonic editing rabbit hole I go.

I am going to take a shot at using the 205 program as the main container that will contain all of the PLC logic to support the whole family. I can separate out the stuff that just can't exist in the 205 into separate User Programs that will be the base BRX hardware configuration program. Then at least spinning a new rev is only as complicated as creating a revisioned copy of the BRX program, copy pasting the logic from the 205 program into it, and building it there. It still leaves cross documentation as an area for human error, but that seems about as good as it can get for just needing to work in the interim, unless anyone has any ideas of automating/scripting some of these processes to take the human out of the pipeline?

[franji1]

Look at the File->Export->Project mechanism.

The files are text.  The form is managable from a simple "generate" standpoint.

The #BEGIN SYSCONFIG sections would be different for the two architectures.  No need for DEVICE or MEMCONFIG sections since you have the SYSCONFIG section.

The import mechanism supports #include <filename> mechanism, so you could have all the common code in one .txt file, then have the top level .txt file for 205 and BRX include the
1. #include hardware specific SYSCONFIG portion (a 205 file and a BRX file)
2. #include Common logic (common between the two)
3. #include hardware specific logic (MRX/MWX code-block, 205 file and a BRX file)

This mechanism automates how COPY/PASTE works.


EDIT: So do File->Import->Project for each of the two 3 line .txt files (3 #includes) to generate the two .dmd project files.

[RobertW]

The import mechanism supports #include <filename> mechanism, so you could have all the common code in one .txt file, then have the top level .txt file for 205 and BRX include the
1. #include hardware specific SYSCONFIG portion (a 205 file and a BRX file)
2. #include Common logic (common between the two)
3. #include hardware specific logic (MRX/MWX code-block, 205 file and a BRX file)

This mechanism automates how COPY/PASTE works.


EDIT: So do File->Import->Project for each of the two 3 line .txt files (3 #includes) to generate the two .dmd project files.

This is excellent information. I was expecting to do some of this as one avenue, possibly using a script editor to shove the files together manually, but I didn't know that there were #IMPORT directives. Is there documentation about this somewhere? I didn't see it in a quick search of DMD's help system.

[franji1]

This is excellent information. I was expecting to do some of this as one avenue, possibly using a script editor to shove the files together manually, but I didn't know that there were #IMPORT directives. Is there documentation about this somewhere? I didn't see it in a quick search of DMD's help system.

Sorry, no.  I highly recommend NOT tweaking any of the content of the SYSCONFIG or any non-trivial parameters in the instructions.

High level control like we discussed here, yes.  The meaning of a 0x4F10 flag parameter in a AXSCRIPT instruction - sorry, no.

EDIT: The one "tweak" you can do to a System Configuration is to ADD new data-blocks and heap items to the Memory Config, also ADD User Data Types in their own human readable #BEGIN/#END sections (and create heap and blocks of those UDTs).  Again, no documentation, but try doing the Project Export with some user blocks of user data types to get a feel of the general form of those #BEGIN sections to be able to more incrementally tweak the Memory Configuration part of the encrypted System Config section.