Host Engineering Forum
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
May 29, 2017, 03:49:50 pm


Login with username, password and session length


Pages: [1] 2 3 ... 10
 1 
 on: May 28, 2017, 12:45:04 am 
Started by Abubrowski - Last post by Abubrowski
A client of mine would like to monitor uptime/downtime, line speed and several other things via personal computer.  Suggestions would be appreciated as to best software to accomplish this.  I am planning on putting in a brand new PLC that will monitor certain aspects of the machines.  What is the best software for their computers to utilize and see this information?  The software would need to do trends and record information.

 2 
 on: May 27, 2017, 01:11:42 pm 
Started by Garyhlucas - Last post by BobO
Which brings up another topic. BRX CPUs have a microSD slot. Can this be used to reload a program? Is there a routine to save a current program and ALL variable data to the SD card? This would be totally huge. Supply the customer with an offline backup of each CPU after we have done startup. Keep one spare unprogrammed CPU as a spare. We could even send unprogrammed CPUs to a customer and they could reload their own program. Having experienced lots of AB PLCs that have lost their program, including having to fly out to a customer on Thanksgiving to do a reload this is a high priority item for me!

Not yet, but that is on the wish list.

We do have a decent answer for updating programs though. Look into DMLoader. Click "File->Export->Generate DMLoader Image..." to generate an image. We tried to build DMLoader to meet the needs of OEMs in a production environment, as well as updating in the field.

A brief description of each option:
1. DMLoader Image Password: Allows you to lock the image file from unauthorized use.
2. Comm Session Password: To unlock the PLC for update.
3. $ProductID: Allows you to specify a magic number in the image that must be present in the PLC. If you select "Require", DMLoader will refuse to update any PLC that doesn't have the correct value. If you select "Set", DMLoader will go ahead and set the value when it updates. "Require" is for the customer end, "Set" for production. Ideally any magic number should also be set by ladder code.
4. $ProductVersion: Use to warn of potential downgrades.
5. PLC Operating System: DMLoader can include and update OS firmware as part of the update.
6. Program, SysConfig, and Docs: This is the program.
7. Retentive Memory Image: You can include a memory image created in Memory Image Manager to initialize any retentive PLC memory.
8. Password Configuration: You can include a complete user config.
9. Use Banner: Allows you to bind a graphics file to the image, which DMLoader will display at the top when the customer opens the image file. Makes it look more like 'yours'.
10. Use Provided Instruction File: You can provide an instruction file that DMLoader will show on the first page after loading the image. If not specified, DMLoader shows some generic instructions.




 3 
 on: May 27, 2017, 12:22:38 pm 
Started by Garyhlucas - Last post by Garyhlucas
As quickly as possible.
Waiting on analog input modules! ADN.

 4 
 on: May 27, 2017, 12:19:16 pm 
Started by Garyhlucas - Last post by Garyhlucas
Okay,
Sounds like a remote CPU makes the most sense. It also means we can talk Modbus to the VFD drives and use the onboard highspeed I/O. Likely we will use the same CPU as that removes yet another part from the spares list, an important consideration for us.

Which brings up another topic. BRX CPUs have a microSD slot. Can this be used to reload a program? Is there a routine to save a current program and ALL variable data to the SD card? This would be totally huge. Supply the customer with an offline backup of each CPU after we have done startup. Keep one spare unprogrammed CPU as a spare. We could even send unprogrammed CPUs to a customer and they could reload their own program. Having experienced lots of AB PLCs that have lost their program, including having to fly out to a customer on Thanksgiving to do a reload this is a high priority item for me!

 5 
 on: May 26, 2017, 10:35:40 pm 
Started by BobO - Last post by franji1
  *  I can't copy stages in Data View using Ctrl Enter, so again you have to type in the name of every stage value that you want.


Use Ctrl+Shift+Enter to advance to the next field, which in this case is the next Stage bit

 6 
 on: May 26, 2017, 09:44:33 pm 
Started by Garyhlucas - Last post by BobO
We have an EBC in development for BRX. It will likely launch Q4, with a batch of other Host modules.

The last date I heard on analog expansion was mid-August, which seems achievable. The tech seems all stable, it's now just launch logistics.

One consideration of remote I/O vs a remote CPU is the high speed I/O requirement. We are going to be developing the BX-HSIO, which adds more of the same high speed I/O functions as are on the brick, but the BX-HSIO will be limited to the local base. Since it is very easy to move data between Do-more CPUs on all platforms, I would plan on using another CPU rather than remote I/O.

 7 
 on: May 26, 2017, 05:27:44 pm 
Started by Garyhlucas - Last post by Controls Guy
As quickly as possible.

 8 
 on: May 26, 2017, 03:51:46 pm 
Started by Garyhlucas - Last post by Garyhlucas
Our products look like they are going to take off in a big way and we are trying to figure out how transition to BRX.  Our product is a very small but advanced Membrane BioReactor (MBR) waste treatment plant.  We are trying to take waste treatment from custom built one of a kind plants, to a Product that gets built exactly the same every time.  Some jobs though have a lot of auxiliary equipment like screens, mixers, pumps, and chemical dosing that are not part of the biological treatment process, but are necessary to building a complete plant.  So we plan on having a remote I/O panel to handle these functions when the job requires it.

Our total for the plant I/O currently is 8 digital inputs, 32 digital outputs. 16 analog inputs, and 3 discrete inputs and 3 discrete outputs on a high speed counter.  It looks like a BX-DM1E-36ED13-D covers a lot of the I/O and can take 8 expansion modules.  We'll need 16 more analog inputs, and 16 more digital outputs so I am guessing 4 8pt modules and room for 4 more to handle future needs.

However we are bidding a job right now where that remote I/O will be needed too.  This remote I/O will be on another skid located in another room.  Since we are currently using Terminator I/O this a is simple just add a communication module to the same kind of Terminator I/O or even a second Do-More CPU. Currently this works well as all I/O modules are the same type.  So how would we do this assuming the analog input modules are actually available AnyDayNow?  Can a BRX CPU be used simply as a remote I/O comm module for the remote I/O?  Is there a plan for a comm module to do remote I/O in the near future?  If we needed high speed I/O in the remote location would using BRX CPU with the high speed inputs be the way to go?  We also might want modbus in the remote location to talk to PLCs, so maybe that influences the decision of what to use for communication too.  The cost difference between a CPU or comm module is not a consideration, ease of setup and programming is more important.

Thanks,

 9 
 on: May 26, 2017, 09:19:52 am 
Started by BobO - Last post by BobO
  * I can't renumber blocks of stages in Documentation Editor using Ctrl R like I can with X,Y,C,V, etc elements. It's really painful to renumber stages one at a time.

Do-more is far more complex than DL, and creating stages as global block memory was going to create a level of complexity that was unmanageable. Making stages struct fields solved many problems, but introduced a few others. We do have plans for a Stage Manager whose sole purpose is renumbering and reordering stages. I think this issue will go away when we add that.

  * While in the Documentation Editor, stages are not listed numerically, they'll be in an alphabetical order such as S0, S10, S100, S11, S30 then S4, etc.

That's a known issue and should be fixed in 2.1.

  * I can't enable or disable a stage while in Data View.

We can look at adding a stage set/reset option to the Data View. It's not a memory operation per se (which is why it isn't there), but I guess from a user's perspective that's really academic.

It is possible to do it now from the Project Browser. Right click on the stage, select Debug Code-Block, and then Enable/Disable Stage. I'm thinking we have a case to add it to the right-click menu on the stage itself.

  *  I can't copy stages in Data View using Ctrl Enter, so again you have to type in the name of every stage value that you want.

That's there. Struct fields are iterated with Ctrl-Shift-Enter.

 10 
 on: May 26, 2017, 07:34:21 am 
Started by BobO - Last post by mark.troutner
I would really like to see some enhancements to Stage. For instance:
  * I can't renumber blocks of stages in Documentation Editor using Ctrl R like I can with X,Y,C,V, etc elements. It's really painful to renumber stages one at a time.
  * While in the Documentation Editor, stages are not listed numerically, they'll be in an alphabetical order such as S0, S10, S100, S11, S30 then S4, etc.
  * I can't enable or disable a stage while in Data View.
  *  I can't copy stages in Data View using Ctrl Enter, so again you have to type in the name of every stage value that you want.

Pages: [1] 2 3 ... 10
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM