Announcement

Collapse
No announcement yet.

Another Productivity 3000 programming flop

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • MikeMc
    started a topic Another Productivity 3000 programming flop

    Another Productivity 3000 programming flop

    Well after waiting for 3 releases for Automation Direct to fix the printout of the Productivity 3000 programming software it still looks like crap. Unless you you a font so small that it is almost impossible to read, there is no chance of getting a line of code to print on one line.

    My first printout of the new version (hoping against hope) was so mis-aligned that you would be ashamed to show it to a client. It looks like something one of my grandkids would to for a grade school paper. Despite claims that they would fix this, NOTHING was done. You still have to hack on the ladder logic to get it to print on one line even though it looks just find on the screen.

    It is almost easier to use something like Snipit to capture the ladder logic and save it as JPG files than it is to try and get an entire program to line up correctly.

    I was ashamed to show the last printout to the engineer and this was after Automation Direct had worked on it trying to get it presentable. And the only comment they had to make when they sent the printout back was that I was initializing my variables in the program wrong. Too bad that they don't understand enough about realworld programming to understand that you don't want to pre-load variables everytime the program starts. Maybe the variables are ok as is and you only want to reload them if some for of indicator says that the variables are not loaded.

    I am so agrivated with Automation Direct and their lack of care for producing the best software they can that I am ready to go back to AB full time. When was the last update you received for Directsoft 5? Can you retrieve the upper level double word variables from a Click using another Automation Direct PLC. I still cannot, and it does not matter what the master PLC is, the Click still returns an error when trying to retrieve this data. And this has been almost 2 years but still no fix.

    Their number one rating in customer servce damn sure does not apply to fixing problems that are reported. I will be that the weird problem of making the background color and foreground color the same on some data screens still exists. Or the weird offset of the selection block when it select part of the previous rung and part of the following rung. Their answer, we have never seen this before. If I had a dollar for everytime that I have heard this from them and eventually it was fixed, I would be running for president.

    If I have another crash of the Productivity software while working in it, I am scrapping the whole P3500 system. I have this last project to finish after I had draw out the ladder logic so it will look correctly in the printouts and then they can junk the system for all I care. The same goes for the Click. Such simple requests as to have an add on analog module still don't exist. And there is mothing cheap about having to upgrde a complete processor because I needed one more stupid analog input. If I am going to have to mix the systems then why not stick with the AB MicroLogix 1400 where I have Ethernet, serial and module expansion INCLUDING analogs for the same price that I am spending to kludge up a system for one more analog.


  • LWgreys
    replied
    Originally posted by kewakl View Post
    Does this method make a legible print on a respectable paper size?
    -or do you use this to experiment until you find a usable font/paper setting?

    Sometimes it just has to be on paper. For those times, I print landscape 11x17.
    I use a font size based on the print preview of the task.
    You can use standard paper sizes or use the custom sizing to any width, height portrait or landscape. Plus resolution and scaling. I use it when I want to dump the document printout but only want to really printout the X and Y portions. Or just want to have a PDF of the ladder on computer file for reference but not wanting to print it. Many uses, works with all software print to printer command. Just select print with doPDF instead of the real printer.

    Yes I do use it to find a usable font/paper setting. Better this way than wasting paper.
    Attached Files

    Leave a comment:


  • kewakl
    replied
    Originally posted by BobO View Post
    For virtually everything I do in embedded development, I avoid data shifting like the plague. Ring buffers work beautifully and completely eliminate the performance hit to large samples. I admittedly know very little about P3K programming, but doing this in Do-more is quite simple, so I would expect P3K can do it as well. I have even gone as far as maintaining running sums...adding to the sum as I add samples, and backing values out as I remove samples...just to keep statistical computations quick.
    I didn't do an exhaustive study on saving that data, but shifting arrays seemed to do what I wanted, and it will be easier for others to understand my intent.

    I appreciate all of your comments.
    Last edited by kewakl; 10-23-2014, 08:46 PM.

    Leave a comment:


  • BobO
    replied
    Originally posted by kewakl View Post
    1. analog card updates 112mS per card update - sampling more frequently will return the same measurement
    Can't comment on analog performance...Host doesn't make analog.

    Originally posted by kewakl View Post
    2a. saving the measurements locally - I bumped the watchdog timer while shifting arrays - so I reduced my sample count
    2b. total number of measurements to save - the more samples that I attempt to store locally, the longer it takes to shift the array values
    For virtually everything I do in embedded development, I avoid data shifting like the plague. Ring buffers work beautifully and completely eliminate the performance hit to large samples. I admittedly know very little about P3K programming, but doing this in Do-more is quite simple, so I would expect P3K can do it as well. I have even gone as far as maintaining running sums...adding to the sum as I add samples, and backing values out as I remove samples...just to keep statistical computations quick.

    We do have some statistical functions built into the MATH box (AVGR, MAXR, MINR, SUMR, STDEVR) but those were not really intended for very large sample sizes. However, it is very easy to do operations like that in program code, and the timeslicing feature of program and task blocks prevents long loop operations from hurting scan time beyond the timeslice you configure. Pretty sweet to be able to churn through 10k samples computing whatever you want and have effectively no bump to scantime.

    But again, choose what works best...I want folks to be informed, but I'm honestly not trying to sell you a Do-more. It's in Host's best interest to have you happy with what you use, even it is means not using our products.

    Leave a comment:


  • kewakl
    replied
    BobO,
    Thank you for weighing in.
    I agree with your 20%/100% statement.
    wrt storing the data: I only collect/store it during the cycle and when the next cycle starts, I overwrite it.

    Currently, I have no requirement to maintain this data as this is not a final test.
    I collect data on all of my electrical processes so that I can prove that the process is performing as desired.
    Some people have problems believing that a PLC can read 100 voltage and 100 current measurements 2 to 4 times a second -- and process that data.
    The bottlenecks for my measurement frequency are:
    1. analog card updates 112mS per card update - sampling more frequently will return the same measurement
    2a. saving the measurements locally - I bumped the watchdog timer while shifting arrays - so I reduced my sample count
    2b. total number of measurements to save - the more samples that I attempt to store locally, the longer it takes to shift the array values

    Leave a comment:


  • BobO
    replied
    Originally posted by kewakl View Post
    That is an interesting idea, but some of my arrays are larger than the 200+Kbytes supported by Do-More.
    I do alot of voltage/current measurements on quantities of up to 100 capacitors at a time - over a several hour period. These values are stored in arrays - using a 'sliding window' to minimize the amount of data required. The data that I do store is used to 'prove' a failure and to give engineering a set of data around the fault event - so that they can 'see' what the capacitor was doing for several seconds before and after the event.
    At present, I have no intention to save this data to a database, so it remains local and I copy from dataview to Excel when required. -- another wonder of ethernet!
    As was mentioned we do have plans to add a flash based file system and the utilities needed to manage it remotely. Although truthfully, unless I actually needed the data for my ongoing operation, I wouldn't store it in the controller, I would go to a PC. It is literally less than a 5 minute effort to start streaming data to a file through DMLogger, and we have customers doing similar test applications logging data at 100Hz.

    That said, this may be clear example where P3K is a better choice. In the end, ADC (and Host) is best served for their customers to use the products that fit the needs. One of my favorite sayings here at Host is: "I'd rather apologize to 20% of the customers for what I don't do, than to apologize to 100% for what I did poorly." That phrase is core thinking for us and guides many of our design decisions.

    Leave a comment:


  • BobO
    replied
    Originally posted by ControlsGuy View Post
    Wow, I think you may have found the scenario where a P3K beats a Do-More if you need megs of memory! (Although future Do-More CPU's will have a file system and flash storage which might meet your needs.)
    Yeah, but it begs the question of how much data you need *on* a PLC. If you are trying to store bulk data, PCs are great at that, and we make it very easy to put data directly to a file on a PC. If you are trying to store megs of data on the PLC and expect that data to be part of the control process, you have moved outside of what the current Do-more controllers were designed for. It has never been our intention to be "all things to all people", but we do want to be high-performance low-cost machine control, and that has driven our design choices.

    Leave a comment:


  • kewakl
    replied
    Originally posted by LWgreys View Post
    So I don't waste paper I use Free PDF Converter. It acts just like a printer but you output to a PDF file. The program can be customized to fit your printout needs. Download doPDF at www.dopdf.com and STOP WASTING PAPER!
    Does this method make a legible print on a respectable paper size?
    -or do you use this to experiment until you find a usable font/paper setting?

    Sometimes it just has to be on paper. For those times, I print landscape 11x17.
    I use a font size based on the print preview of the task.

    Leave a comment:


  • LWgreys
    replied
    So I don't waste paper I use Free PDF Converter. It acts just like a printer but you output to a PDF file. The program can be customized to fit your printout needs. Download doPDF at www.dopdf.com and STOP WASTING PAPER!

    Leave a comment:


  • ControlsGuy
    replied
    Wow, I think you may have found the scenario where a P3K beats a Do-More if you need megs of memory! (Although future Do-More CPU's will have a file system and flash storage which might meet your needs.)

    Leave a comment:


  • kewakl
    replied
    Originally posted by ControlsGuy View Post
    You could turn all the P3K's into dumb I/O running from Do-More CPUs (yes, I really like Do-More enough to do that). Then you wouldn't have any (or much) program per se in the P3K's, you'd just have Do-More's with some unusual remote I/O.

    Understand if it's not practical in your scenario, but it is an option where you might be able to jettison the parts of P3K that annoy you without having to buy all new I/O.
    That is an interesting idea, but some of my arrays are larger than the 200+Kbytes supported by Do-More.
    I do alot of voltage/current measurements on quantities of up to 100 capacitors at a time - over a several hour period. These values are stored in arrays - using a 'sliding window' to minimize the amount of data required. The data that I do store is used to 'prove' a failure and to give engineering a set of data around the fault event - so that they can 'see' what the capacitor was doing for several seconds before and after the event.
    At present, I have no intention to save this data to a database, so it remains local and I copy from dataview to Excel when required. -- another wonder of ethernet!

    I do immediate analysis to determine and automatically disconnect failures. It works as is, and I do not have enough experience with Do-More to know if it supports the array manipulation and statistics that I require.
    Part of the rationale for choosing the P3k was the 50MB memory, the CPU speed, the analog i/o capability and comms over ethernet.
    So far, the first three points have been remarkable well met. It is just some of the other things that have let me down - some from the start! But I chalked that up to New Platform. That doesn't comfort me now as it did nearly 3 years earlier.

    Originally posted by PLC_PM View Post
    Gentlemen you bring up very valid points and we do appreciate your feedback!
    .......
    Unfortunately, anytime you edit an existing code base you run the risk of introducing a new problem. Everyone has experienced this and as mentioned it’s an area we take very seriously, one we are striving to improve on. Again, I cannot express how much we appreciate when our customers tell us what you want. This is how we improve.
    Agreed! Many new features - most that I am hesitant to use because I have been bitten by almost each new version of P3k software - as indicated above.
    Maybe it is time for AD to begin a NDA BETA 1 2 and a CLOSED FORUM for some of these issues to be found before the laundry is aired in these forums. (my post count here might still be in the double digits)
    I know that it is not AD policy, but surely policy is changeable with overwhelming cause. Heck, AD's name is changeable - PLCDirect ------> AutomationDirect.

    Leave a comment:


  • PLC_PM
    replied
    Gentlemen you bring up very valid points and we do appreciate your feedback!

    Printing is an area that we’ve been working on in almost every release so we can provide a better solution based on the feedback that we’ve received. Printing is complicated when you’re working with long tag names and larger function blocks. We’re continuing to strive to make it better and I do believe it’s much improved, but it doesn’t mean we’re satisfied. As ‘kewakl’ mentioned, the margins were retained in v1.9 as they should be, but that regressed in v1.10 and has been fixed in the next release candidate. We do apologize for this setback.

    The regression issue is a serious topic for us and we’re putting a lot of emphasis on our pre-release QA processes, we want to improve with each and every new version. We have been making tremendous enhancements to the software, including, but not limited to:
    • Structure data types
    • Tag I/O reassignment
    • EtherNet/IP
    • Bit of word
    • Tag name wrapping
    • Many Dataview updates – column sorting, add/delete rows, improved graphing, etc.
    • Improved cross reference
    • Improved search & replace
    and many more features that are waiting for the next release. All of these are based on specific feedback from our customers.

    Unfortunately, anytime you edit an existing code base you run the risk of introducing a new problem. Everyone has experienced this and as mentioned it’s an area we take very seriously, one we are striving to improve on. Again, I cannot express how much we appreciate when our customers tell us what you want. This is how we improve.

    Leave a comment:


  • ControlsGuy
    replied
    You could turn all the P3K's into dumb I/O running from Do-More CPUs (yes, I really like Do-More enough to do that). Then you wouldn't have any (or much) program per se in the P3K's, you'd just have Do-More's with some unusual remote I/O.

    Understand if it's not practical in your scenario, but it is an option where you might be able to jettison the parts of P3K that annoy you without having to buy all new I/O.

    Leave a comment:


  • kewakl
    replied
    Originally posted by ControlsGuy View Post
    Don't let it sour you on ADC PLCs in general and go back to AB.
    I cannot afford the Popeye-style milking arm of RS/AB.
    I like the (controllers) hardware and (editor) software, but the support is ____________ (fill in the blank!)
    And (if I remember correctly) the comms software was notoriously difficult to get working for anything other than a simple Go Online.
    On the SLC platform, almost every other model required another comms hardware device.
    I never got my USB-PIC adapter to install/connect!
    RS/AB was always 2 or 3 versions behind in terms of what PC OS they supported.
    AB-Tech had to remote-in (2 hours) to install RS-Logix500 Starter 8.20(CPR9). It installed OK, just failed activation.


    So, NO. That ain't happening!

    Oh well, this isn't an AB grievance thread, it is an AD issue thread.

    Originally posted by ControlsGuy View Post
    Just start buying Do-Mores instead of P3Ks! Do-Mores rock!
    I would consider Do-More, but I have a significant investment in networked PACs with hundreds of analog channels per station.
    I would rather maintain ALL PAC machines instead of mixing platforms.

    Leave a comment:


  • ControlsGuy
    replied
    Well.....OK Nancy! I was taking about Do-More (and I don't work for ADC, I'm an integrator). Get back to me when you know what you're talking about.

    Leave a comment:

Working...
X