New features wanted!! Apply here!

[BobO]

To ATU...regarding your question about custom types and such: The short answer is 'yes', although perhaps not until rel 2. We already have structures working, and there is no good reason not to allow customer created types....however...the type editor and user type management will take some additional work that we may not be able to get into the first release. We already have two string related built-in types SS and SL: short strings (up to 64 chars) and long strings (up to 256 chars). In thinking about what you said, we arrived at the conclusion that allowing customers to create string blocks of arbitrary lengths would not be difficult. Meaning....if you wanted a whole bunch of 12 byte strings, we should be able to accomodate that when we add user created structs.

To Controls Guy...regarding array indexing: Sadly, our array limitation is also limited to depth of one...you can do Block[Vn].Field, but not Block[D[Vn]].Field. Not sure how we'd get that into our implementation, which is still just a conventional PLC....not a compiler.

[BobO]

Hmmm...let's see if we can create a real panic.

The attachment is a months old screen shot of the PC Sim with the FOPDT process simulator open, along with a trend view of some PID loop goodies. That is not the PID view, which is a whole new view based on the general purpose trend view. The new PID view wasn't complete at the time I grabbed this screen shot. Everything you see here, along with 2 rungs of the ladder code, can be set up in a few minutes.

[ATU]

Looks nice. Thank you for putting Parameter explanations right there where you need them. I have a difficult time keeping it all in my head and just being able to access that quickly is very helpfull.

 Back to  the  Data structures.  Will you be able to monitor and change real time values in the variable data table or will you have to create a Data View to be able to that? CLx has a Monitor/Edit tab which is handy, however they don't make it a tab viewable with your programs. It makes it difficult to switch easily between the program and the variable list and you have to go upto the Windows menu to select it or select it from the tree.  Also you don't have a choice of selectively monitoring what is in the list. It's either all or nothing. If you have a lot of strings, it bogs down the monitoring update noticiblly when viewing that part of the data table.

I would much rather have 1 list on a Tab with your programs that you can edit/Add/Delete and with a simple check box to turn that variable on for monitoring.  Maybe have a check all or uncheck all at the top of the column.

By the way what is the difference between D and R memory?

[b_carlton]

Wow - this is really getting exciting. I know you guys (and gals?) are excited because you are controlling both the CPU and the programming package. I just hope you're not trying to adopt so many features at once that the project won't ever be released.

[BobO]

Bernie...we are trying to do no more than is absolutely necessary in the first release to get the critical infrastructure defined; so much becomes harder after we release. The challenge is sorting what needs to happen now vs what can happen later. That said...yeah...we ask ourselves the same question weekly.

ATU...yes, individual fields can be changed. Currently that happens by data view...but...we are kicking around many great ideas for making that process easier. Please see answer to Bernie for clues as to why stuff might slip into rev 2 or 3. 

[BobO]

Oh and ATU...D memory is 32 bit signed int, whereas R memory is 32 bit float...all part and parcel to the strong typing we have mentioned. The Sim just includes a handful of values for display to make for a nice demo and tutorial tool. Notice the WX and WY types...analog ends up there without further work on behalf of the user...and may be familiar to TI5xx users.

FYI: There are many more built-in types that aren't included in the Sim display. 

[ATU]

Totally understandable. You have to draw the line somewhere or you will never complete the 1st release. However, these thoughts sift from my head and I have to get them out and written down when they come to the surface or I will forget. I've worked with many different programming packages and trying to relate what I think are the best implementations and what I would like to see. I don't expect it on the first release, but perhaps if you come across a good idea, you don't want to set something in stone where a good idea can't be realized in the future. 

[BobO]

Bring `em on! This forum becomes a great place for discussion...and archival...that we can refer to in the future when we are looking for new stuff to do.

The problem that we are currently having is that by owning both ends of the pipe...the CPU and programming software...we suddenly find ourselves with a power tool we never possessed before. The first part of that process is to free our minds of previous limits (aka...'there is no spoon') but then once we have freed it, bringing that to a sustainable development plan. The freeing was pretty easy, but the second part...not so much. The question we constantly ask is whether the proposed development affects infrastructure or not, and whether it is easy now or not. Easy now, and we might do it. Not easy now, but not infrastructure dependent, we'll do it later. Infrastructure dependant, regardless of ease, is getting done now.

A great example is our current plan to support modularity...including call-able functions and such. We know what needs to happen, and are going to put all the infrastructure in place, complete with automated testing of required instructions...but...some of the required UI to do it right will have to wait until rev 2. Which means that as far as the user is concered, it really won't be there. But it give us a great confidence that we haven't painted ourselves into a corner with things that are so easy to change now, but are painful...or impossible...later. I hate it, but stuff like this will hold up initial release. But you'll love us later!

[Controls Guy]

Woo hoo!  No more futzing around with the pointer method or multiplexing!

Don't forget the enhanced tabular data view (many values per screen).

[plcnut]

All this looks Great ! I just hope were not looking at an AB price tag when it's all done. Thats what knocks out the little guy like me BTW The PID trending/tuning looks great! Are you changing the PID trending for DS or is this only for the new controller? Thanks

[BobO]

No, the existing DirectLogic PID view will remain the same. The view in the picture is actually just the new Trend View which will be a feature in the new controller, at least initially. There is also a new PID view (for the new CPU) but it wasn't complete at the time that I took that screen shot several months ago.

We may retrofit Trend View into classic DirectSoft...but, it may have a few limitations. The new CPU is strongly typed, and the new programming environment makes big use of that fact. Since the existing controllers are not strongly typed, it becomes necessary to add some additional UI and back-end complexity to deal with type management.

Price? Trust me, you'll love it.

[Controls Guy]

So it sounds like there will be separate programming packages for the new and "classic" controllers rather than this being "DirectSoft 6.0"?

[franji1]

We like to think of it more as DirectSOFT being different between the 305 family  as compared to 05/06/205/405 family.  The PLC submenus are different between the PLC families, the instruction sets are vastly different, but the basic editing and UI are similar.  So as much as 305 and 05/06/205/405 are "different packages", then the answer is "yes".  However, there are still a lot of similarities.

I know that makes it clear as mud!   

[Controls Guy]

Uh...ok...I think.  So will I have to purchase, install, and maintain two programming packages or will a single new package program all PLC's including the normal stuff (05, 06, 205 'classics', 405's), the 305's, and the new, '270 Super' or whatever?

[franji1]

Uh...ok...I think.  So will I have to purchase, install, and maintain two programming packages or will a single new package program all PLC's including the normal stuff (05, 06, 205 'classics', 405's), the 305's, and the new, '270 Super' or whatever?

We eliminated the separate packages with Rel 5.  You used to be able to purchase a BRICK ONLY, or a 205 ONLY or ?? ONLY.  We are hoping to stay away from "separate" packages (it sounds like you would agree), but you'd be surprised how many people look to save a buck here or there and WISH there would be, say, a "270 ONLY" package (or whatever).  We ended up with people with Rel 2, 205 ONLY and a Rel 3, 05 ONLY, complaining when they bought the "upgrade" for Rel 4, that it could not program an 06!  Guess what you get when you upgrade a 205 only and an 05 only package - a package that can ONLY program 205 and 05!!  Rel 5 only comes in one package - you get it all.  Host bit the bullet and when you upgraded ANY previous "ONLY" package, you got to the FULL package for Rel 5.  We really want to stay away from that mess! 

I really don't want to discuss any marketing now anyway (it's WAY too early).