Hello? Hello? Hello? Is there anybody in there? Just nod if you can hear me.

[BobO]

Form factor?

- Bricks with stackable expansion.
- Three CPU housing sizes, with four CPU classes:
  a) 20DI/16DO/4AI/2AO
  b) 10DI/8DO/1AI/1AO
  c) 6DI/4DO/1AI/1AO
  d) pure modular, no I/O
- Up to 8 expansion modules plug on the end, ala CLICK, but backplane is very fast.

New features?

Definitely.

- Analogs are selectable by channel for all voltage and current ranges. Integrated scaling.
- Interrupts
  a) Up to 32 Interrupt Service Routines, which are a new code block type
  b) Event interrupts. Think logic analyzer triggers...if X1 is true and X4 is false then on the rising edge of X0 or falling edge of X10 fire routine XYZ.
  c) Timer interrupts. Recurrent or single.
  d) Register match interrupt...if HSC Chan 1 is equal to 1234 fire interrupt ABC.
- Speaking of new code block types, we've added subroutines. At this point they are still parameter-less, but we added a really nice call instruction that copies parameters into sub's internal data and will import the call signature from other call instructions. Not true parameter passing, but still super functional.
- High speed inputs. Pretty much the same features as CTRIO2 input channels assignable to any combination of inputs.
- High speed outputs. CTRIO2 preset tables and electronic cam tables implemented *in hardware*...1us response time.
- Integrated motion. This is still in development, but the goal is to be better than CTRIO2 Axis Mode.
- Some high speed I/O and motion functions are supported in Interrupt Service Routines, and interrupts can be reconfigured by instruction...meaning...you can chain together interrupts into highly complex functions.
- SdCard slot
  a) Simple logging to essentially unlimited files. Instruction based so you can have as many as you can fit.
  b) Full file I/O instruction set...FILEOPEN, FILECLOSE, FILEREAD, FILEWRITE, FILEDELETE, FILETRUNC, FILEGETPTR, FILESETPTR, FILEQUERY, FILEMKFLDR. You don't like our log instruction? Roll your own. Wanna do a complex file-based recipe solution? Roll your own.
  c) DmD based file manager to read, write, and delete files, as well an manage directories.
  d) EMAIL can send files from SdCard and RamDisk file systems as attachments.

I'm sure there are more, but I need to write some code...

Terminal type?

5mm Euro on bricks, 5mm Euro on 8 and 12 point expansion, and 3.8mm Euro on 16 point expansion. We built it a little bigger to accommodate 5mm everywhere possible...a man shouldn't have to work on his PLC with the same screwdriver he uses on his eyeglasses. It will also have ZipLinks.

As for date will it be this year?  Have a project coming up that id like to try a do more type cpu in. 

No commitments on dates...but...we are very much hoping these guys will be controlling some Christmas trees this year.

[deep6ixed]

Remember the time filtered input idea I listed over in the suggestion post?

If Input X stays on or off for Y time, then the bit is true.  Is that still a possibility?

[BobO]

Remember the time filtered input idea I listed over in the suggestion post?

If Input X stays on or off for Y time, then the bit is true.  Is that still a possibility?

Sure. As long as we're talking about milliseconds, and not microseconds, that's a simple software based timer that can be added for all Do-more controllers, not just the new bricks. Right now we are focusing on new features specific to the new platform, but we are definitely planning many more enhancements for all Do-more controllers as time permits.

The instruction would take about 30 minutes to add to the controller...it's DmD that takes time.

[BobO]

Was out walking, thinking about the filtered input. I could see several ways I might like it to work:
1. Delayed turn on. Immediate turn off.
2. Delayed turn on. Delayed turn off.
3. Delayed toggle.

Would take a timer structure. Time would be expressed in ms.

Probably could optionally invert the input, but that isn't really a mode.

[Controls Guy]

Some of this stuff can be done (albeit less efficiently) in ladder.  Obviously, you can debounce an input already in ladder with timers, but I'm thinking more of when we have parameterizable user functions, if you want a debounce, you can write one.  (A debounce function is in fact one of the first boxes I wrote in the latest version of Siemens S7)

That would free you to do in hardware only the things that can only be done in hardware, AND would leave you more time to implement user functions! 

[Garyhlucas]

I've hooked our cart to your horse. I'm building small waste water treatment plants that use ultrafiltration membranes.  The first one is delivered and awaiting startup. Looks like we get a PO for two more next week and another shortly after that. We just became the basis of design for another job and we have a couple of more waiting to commit.  So while I've only bought two Do-More systems so far, things are starting to look exciting and I have lots of uses for the bricks too.

[BobO]

I've hooked our cart to your horse. I'm building small waste water treatment plants that use ultrafiltration membranes.  The first one is delivered and awaiting startup. Looks like we get a PO for two more next week and another shortly after that. We just became the basis of design for another job and we have a couple of more waiting to commit.  So while I've only bought two Do-More systems so far, things are starting to look exciting and I have lots of uses for the bricks too.

Awesome!

[deep6ixed]

Some of our applications would require time in seconds, so this would take a little more work.

[BobO]

Some of our applications would require time in seconds, so this would take a little more work.

That's easy. If you were needing microseconds, that would be hard.

[deep6ixed]

Here's an example:

We draw wire down from a specific size to another, and we take it up a tower to a drum and back down to straighten out all the loops, at the top of the tower there is a plate that free swings on a pivot.  The entire time the machine is running, the plate is swinging back and forth.  We have a timer that waits until it's been toggled for a full 2 seconds before it actually throws the alarm and shuts the machine down.

[Controls Guy]

But if the time frame for your alarm is several seconds, what would be advantage of doing the filter in hardware rather than software?  If I were doing that application and I had both hardware and software filters of that range available, I actually think I'd rather do it in ladder because it clearly exposes the alarm logic to someone looking at the program.  A hardware filter configuration OTOH might go unnoticed.

As I see it, hardware signal handling has value when the processing needs to be done at significantly sub-scan speeds.  High speed counting on dedicated or general purpose input channels, for example.

[BobO]

That's the point...If he didn't need microseconds, it can be a simple timer instruction rather than hardware. Very easy to implement.

[Controls Guy]

Right, you and I are on the same page.  That was addressed to him.

[BobO]

Right, you and I are on the same page.  That was addressed to him.

I don't actually remember if the OP ever mentioned a hardware function. I was attempting to confirm that his app wouldn't require it. But for the record, the inputs already have hardware based digital filters on them.

[Controls Guy]

He probably didn't, but he said he had the application working now, and what else could he be using but software timers, right?  So then, if he's asking for something on this thread, I assumed he must have been thinking hardware.