Disruption in the Automation World, and a practical PLC Code Generator to get started
- Thread starter EdStevens
- Start date
Super interesting thread.
My first controls job was "keying in" code for a senior guy (It was a TI535, if memory serves). He would photocopy printouts of old code and meticulously change the IO addresses, counters, timers - all by hand on paper. At the time they felt like endless programs - it was probably a couple hundred pages, but he only had a handful of rungs per page. It was conveyor-logic (super-repetitive), and when I started doing my own projects I was doing it, as others mentioned, in excel or vb and exporting it into the plc projects.
The code generated automatically had a fraction of the careless errors that the hand-generated code had. Startups went a lot smoother. I had more time to figure out how to locate sensors and calculate timer presets. But ultimately, it's boring to write variations of the same code over and over and I left to do something more interesting.
I'm curious about the comparisons the OP made to software engineering. I agree that our industry seems to be far behind traditional software trends, but I don't think that they have solved all of our problems. There are innumerable IDE's, two-or-three big OS's as well as a bunch of lesser players. Every subset of their industry has their own preferred tools - c, .net, java, python, vbscript, php, sql, html, hlsl, lisp, openGL, directX, just to name a few. I'm not sure we're all that different.
How many of those programmers are there compared to us? I don't know many controls guys anymore that are cranking away writing code every day. Many of us spend more time understanding real physical processes than writing the code to control them. For PLC's, I don't think that our tools are really that bad.
HMI software sucks, however. Somebody should work on that.
My first controls job was "keying in" code for a senior guy (It was a TI535, if memory serves). He would photocopy printouts of old code and meticulously change the IO addresses, counters, timers - all by hand on paper. At the time they felt like endless programs - it was probably a couple hundred pages, but he only had a handful of rungs per page. It was conveyor-logic (super-repetitive), and when I started doing my own projects I was doing it, as others mentioned, in excel or vb and exporting it into the plc projects.
The code generated automatically had a fraction of the careless errors that the hand-generated code had. Startups went a lot smoother. I had more time to figure out how to locate sensors and calculate timer presets. But ultimately, it's boring to write variations of the same code over and over and I left to do something more interesting.
I'm curious about the comparisons the OP made to software engineering. I agree that our industry seems to be far behind traditional software trends, but I don't think that they have solved all of our problems. There are innumerable IDE's, two-or-three big OS's as well as a bunch of lesser players. Every subset of their industry has their own preferred tools - c, .net, java, python, vbscript, php, sql, html, hlsl, lisp, openGL, directX, just to name a few. I'm not sure we're all that different.
How many of those programmers are there compared to us? I don't know many controls guys anymore that are cranking away writing code every day. Many of us spend more time understanding real physical processes than writing the code to control them. For PLC's, I don't think that our tools are really that bad.
HMI software sucks, however. Somebody should work on that.
MitsM83
Member
So I did not go through and read the every post. But I will mention a time I brought this up to an older SI. He said when he was at Purdue before I was born a teacher wrote on the board some ladder logic. Then told the class that this will be the only time they will see that. It will be gone from the field before they graduate and replaced by machine code of some sort (I forget what he called it).
He has since spent 20+ years writing ladder logic. Says every other year there is a new software that is going to make code seamless across the brands, auto write code and change the game... and none of it has caught on yet.
That's not to say it wont.
He has since spent 20+ years writing ladder logic. Says every other year there is a new software that is going to make code seamless across the brands, auto write code and change the game... and none of it has caught on yet.
That's not to say it wont.
What I'm proposing is to build models.
And build the models in a way that they are also the specs/documentation.
Ok that's not the goal. Specs need to be readable by process or other engineers, without them having a coding background. I don't think we want to invent a new language.
Agree that steps 1-3 are needed (URS - FDS - SDS)
It's the manual coding of an SDS that already should contain everything that I'm working on.
And also not have a big part automated testing is not of this age.
Especially in such critical applications.
Any way you can post this is csv, or an image?
[rant]
That is in part true, I see it all the time. However, I feel the need to point out that very often we at the 3:00 AM end of the stick do the best we can with what we have.
I regularly beg and plead for continuing education, but "there is no money" or "you should know that already". My other favorite is "feel free to sign up for any class you are willing to pay for". I would LOVE to go down to Chicago for 2 weeks attend the Fanuc classes that would help keep this plant running better, but I can't afford the 10K in fees, travel, and lost time at work to do it.
I'm pretty sure the multi-billion dollar global corporation I work for could spare the money, and it would ultimately save them money, not cost them. Unfortunately for me Bubba isn't worth investing in, so in the end the company gets what they pay for, and writes it off as "Bubba is incompetent".
[/rant]
Bubba.
Last edited:
Ok I'm trying to understand your approach. Can you review and correct:
So different people keep using the term 'state'. Your 'step' has the same meaning, right?
So a state/step can have on or more actions that are executed during the time the step is active..
Is it as simple to say that in a step you always execute a certain action? Or do you still want to check a condition while in the step to decide if you want to execute the action?
Transferring to the next step:
You will transfer if a transition condition is ok.
What to you do when something is wrong?
You go to a special safety or quality step?
Do you document this, or you just program as you go?
Where do you see the difference between state-based and what you described before? Is it only that state-based might have different transfer states for every state?
Most process integrators use libraries that have standard valves, motors, measurements, PID-controllers, ...
The libraries have matching icons and faceplates for the HMI.
Is this different in machine automation?
How is a bug in an algorithm different from a bug in manually programmed PLC code? For an algorithm you only need to test a limited amount of situations. The algorithm I made does automatic module tests (about 100 at this time and quickly going up) on all the steps in the example. If something would change because a bug in the algorithm then immediately lights up. And if somehow a specific situation is found that is not in the module tests then I can add it, forever eliminating this specific situation.
Again we're currently only testing on a PLC-based Chemical blending process.
Practical experience:
Time saved: huge. I'll post concrete numbers when finished.
Time lost for examining the code: minimal: as mentioned above: we only checked once and now we use automated module tests.
We also do spot-checks and manual integration tests. Those are detailed but focused on the complete functionality, including HMI.
I don't want to change the troubleshooting.
Although there's opportunities for better troubleshooting when you work model-based, but that's another story.
So different people keep using the term 'state'. Your 'step' has the same meaning, right?
So a state/step can have on or more actions that are executed during the time the step is active..
Is it as simple to say that in a step you always execute a certain action? Or do you still want to check a condition while in the step to decide if you want to execute the action?
Transferring to the next step:
You will transfer if a transition condition is ok.
What to you do when something is wrong?
You go to a special safety or quality step?
Do you document this, or you just program as you go?
Where do you see the difference between state-based and what you described before? Is it only that state-based might have different transfer states for every state?
Most process integrators use libraries that have standard valves, motors, measurements, PID-controllers, ...
The libraries have matching icons and faceplates for the HMI.
Is this different in machine automation?
How is a bug in an algorithm different from a bug in manually programmed PLC code? For an algorithm you only need to test a limited amount of situations. The algorithm I made does automatic module tests (about 100 at this time and quickly going up) on all the steps in the example. If something would change because a bug in the algorithm then immediately lights up. And if somehow a specific situation is found that is not in the module tests then I can add it, forever eliminating this specific situation.
Again we're currently only testing on a PLC-based Chemical blending process.
Practical experience:
Time saved: huge. I'll post concrete numbers when finished.
Time lost for examining the code: minimal: as mentioned above: we only checked once and now we use automated module tests.
We also do spot-checks and manual integration tests. Those are detailed but focused on the complete functionality, including HMI.
I don't want to change the troubleshooting.
Although there's opportunities for better troubleshooting when you work model-based, but that's another story.
rdrast
Lifetime Supporting Member
I see absolutely no benefit, and major drawbacks to this approach in any general industry application.
Perhaps in your chemical mixing system, everything is well defined enough to make autogen code work, but it absolutely won't in any other manufacturing industry. In my case here, I have continuous production lines with more than 50 completely different control processes, that must all work together, at the same time, or the product is lost.
When an automatic code generator actually exists, it will be unnecessary as that will be about the same time that actual natural language real time intelligent computers will exist, and they can just be told how to run the process, or taught by having them observe it.
Perhaps in your chemical mixing system, everything is well defined enough to make autogen code work, but it absolutely won't in any other manufacturing industry. In my case here, I have continuous production lines with more than 50 completely different control processes, that must all work together, at the same time, or the product is lost.
When an automatic code generator actually exists, it will be unnecessary as that will be about the same time that actual natural language real time intelligent computers will exist, and they can just be told how to run the process, or taught by having them observe it.
Mark Snodgrass
Member
I have to agree with rdrast, there are simply too many variables within manufacturing to make auto generation of code viable.
Take something as seemingly simple as starting a motor. Sounds easy, push button motor starts, push another it stops. Most programmers could do that with 1 rung. But then try adding more push buttons, interlocks, fault detection, limits,HMI, etc....... How do you write a single piece of code that handles all of the different possibilities? Either your autogen code will be too simple and need lots of modification to make it work within your environment, or will be so long and complex that it becomes unwieldy (100s of rungs, rungs with large amounts of branches).
I have an OEM that has a standard motor control routine, it is 33 rungs long. They used it on a simple turn table that just has a single push/pull and a starter. I was able to pare it down to 8 rungs, could have been a lot less if I didnt keep the HMI interface. And they only work in one industry,with one PLC/HMI platform, so that 33 rung routine covers 99.9% of all variations within our industry. Having to add the variabity needed to cover alll industries and automation brands would jack the size of the routine up immensely.
Take something as seemingly simple as starting a motor. Sounds easy, push button motor starts, push another it stops. Most programmers could do that with 1 rung. But then try adding more push buttons, interlocks, fault detection, limits,HMI, etc....... How do you write a single piece of code that handles all of the different possibilities? Either your autogen code will be too simple and need lots of modification to make it work within your environment, or will be so long and complex that it becomes unwieldy (100s of rungs, rungs with large amounts of branches).
I have an OEM that has a standard motor control routine, it is 33 rungs long. They used it on a simple turn table that just has a single push/pull and a starter. I was able to pare it down to 8 rungs, could have been a lot less if I didnt keep the HMI interface. And they only work in one industry,with one PLC/HMI platform, so that 33 rung routine covers 99.9% of all variations within our industry. Having to add the variabity needed to cover alll industries and automation brands would jack the size of the routine up immensely.
No, it is exactly the same.EdStevens said:
But the library itself is part of the programming effeort, since a machine often have special functions that cannot be covered by a generic library. A process plant on the other hand typically uses a large number of very standardised components.
For machines, this also makes it quite impossible to make everything by an external template. In your mindset, the library is fixed.
"Step" implies that there is a fixed sequence, from start to finish, or from top to bottom. "States" are more universal, you can move back or up, not only downwards.EdStevens said:
SFCs usually have a "next" step, implying that the sequence always follows a start-to-finish order.EdStevens said:
In a state machine, you can make such a fixed sequence if you want to, but not necessarily so.
You can define as many transitions you want, even parallel transitions. But you dont have to have as many transition for each state as there are other states. Only transitions to the states that are relevant.
No, in a nutshell the definition of a state [for a state-machine] is that all outpust remain in the same state.EdStevens said:
You dont "execute" (turn on), and it is not an "action". "Action" implies more than just turning something on or off. It could imply a whole set of things that should be done in a certain sequence.
In a state-machine, if an output changes, then it is a differents state. What I like about state machines is the pure simplicity.
No, but you can have a transition to another state.EdStevens said:
That is what I dislike about S88. You have steps/states, but a step/state is not well-defined. It is as if there are implied sub-states inside each step/state. It is a cludge (IMHO).
It is clear that state-machines can be become very granular. So if you have a complex task, that would result in a huge number of states and transitions. The solution to this is to cut the task up into well-defined sections. This should reflect how the machine is working in sections in the real world. If for example one machine section passes a work-piece to another machine section, then the state machine for the 1st section could trigger a transition in the state machine for the 2nd section, and vice-versa.
Indeed that won't work.
If you have a process that can't be defined by state machines or something similar then this solution is not for you.
I was once involved in the control of a steel furnace and there it would probably also not have made sense.
Another example I'm thinking of is a paper machine.
I think having a process that can be defined as state-machines is key for making code-generation work:
- Batch-processes: definitely yes for most of them.
- Continuous processes: probably not, or maybe if there's step-based start-up and shut-down procedures
- Discrete processes: I keep hearing that they are also state-based in many cases. So my initial guess would be yes.
Yes conveyors / machine handling are a good example of something very repetitive that can autogenerated. Good to see another practical experience, especially the reduction in errors!
Agree that they still have a lot of problems. But it's a different dynamic. Fundamental problems in IT/tech are more openly discussed at multiple locations on the net, and the rate of innovation is much higher.
I personally met hundreds of control guys that at least spend 50% of their time writing code. Most of those are from the process industry.
And I would rather see them thinking about and solving those physical processes instead of having to write repetitive code.
Don't misunderstand me: I love coding. I just don't like repetitive tasks. That's not the reason I've become an automation engineer.
I also want to add this. Some of the features I'm thinking off:
- Generate all the tags
- Generate all the icons of the equipment at the right screens
- Make sure all the standard faceplates work
Are there other features you're looking for?
That's gross incompetence indeed - incompetence from your management
Talking about training: there's some interesting things happening in that space also. Take a look at this company: (not affiliated with them in any way)
https://factoryio.com/
Comment related to what's been discussed in this thread so far about open-source:
The quickest/easiest way to meeting safety requirements IMO would be to target the Ada programming language, which is really what we should be using in the first place instead of these tinker-toy IEC languages. Ada is very similar in syntax (Pascal-style) to structured text, and aimed at real-time/safety/mission-critical applications like avionics, missile guidance systems, medical, etc. It's ANSI/ISO/IEC standardized. There are many tools available to verify operation/safety. Some 32-bit ARM MCUs already have runtime support, just need some I/O to pair up with them. Therein lies the *****.
The quickest/easiest way to meeting safety requirements IMO would be to target the Ada programming language, which is really what we should be using in the first place instead of these tinker-toy IEC languages. Ada is very similar in syntax (Pascal-style) to structured text, and aimed at real-time/safety/mission-critical applications like avionics, missile guidance systems, medical, etc. It's ANSI/ISO/IEC standardized. There are many tools available to verify operation/safety. Some 32-bit ARM MCUs already have runtime support, just need some I/O to pair up with them. Therein lies the *****.
thebuj
Lifetime Supporting Member
First of all, I agree with previous posts that open-sourcing is just saying that this code/hardware is not guaranteed to work, so removing the liability, which is not what companies want. Also, just like Android is Linux based but is not really Linux anymore, open sourcing PLC is not going to propulse the industry in new territories, just create different vendors. And if cost is really the push for open-sourcing, we already have dirt cheap PLC's.
I use PLC's for machines, I never did batch mixing or process. So those are just my interpretations of the claims. I think this is just a case of bad design of a mixing plant and some young smart engineer that came up with a clever way to fix a problem that can already be fixed with existing technology, without upsetting too much the current programmers way of working. Then thinking that his approach is the missing link that will merge software programming and industrial programming and break an industry. The fact is, batch mixing is NOT the entire PLC/DCS industry.
The logical way to design a product, is analyzing your needs, and then choosing the right tools to achieve that. Not choosing your tools and then molding your end product with the tools your have chosen.
I presume that the specs for that plant were decided before the needs were established. Someone decided on PLC's even though it wasn't the best way to do batch mixing. But even there I have doubts, couldn't what he is doing, be done by calling subroutines with parameters? Just like in C++ when you call a function, give it variables, and it will spit out the processed variables? We use subroutines for clarity, but really it can be a very powerful tool to process repeatable code.
I proposed this to my supervisor once when he tasked me to create code for a machine we were redesigning in-house. I told him we could have one subroutine that would handle ALL the motors. We feed it tags when we call it and it spits out the processed tags. Of course he was not very fond of the idea. Not being able to go to the specific ladder and watch the rungs troubled him deeply. I explained to him that with custom tags, we could group everything related to that motor under one main tag and we could see what was going on by watching that tag, and that the HMI would have all the possible faults anyways. He was not impressed, insisted that we would have to teach all the electrical techs how this functioned. I ended up doing a subroutine for every motor. Now I can only imagine if I had asked a group of programmers to do this...
I think PLC's evolved greatly since address based programming and claiming that we program the same way we did 20 years ago is obviously coming from someone who didn't program 20 years ago. The problem is we don't use the new functionalities. We like the address based type of programming. At my workplace, when they have a machine done by an integrator, they ask for aliases to be created that mimic the address type, so that MCC6:4:I.Data.7 becomes S06_0407. Structured text is a perversion, don't ever mention those words. Add-ons are not very welcome either.
Having an electrician background, I really do understand the stubbornness though. You can visualize the electrical flow from hot to neutral when you read a ladder, and literally see where the problem is. Not the case when calling subroutines with parameters or structured text or addons, or any other way than basic ladder. This one reason why basic ladder will prevail.
Automation is fantastic a long as everything is working like intended. But when things go wrong, it's not the bright young engineer that designed the machine that will be troubleshooting the machine, it's the on-site electrical technicians, and like someone said earlier, they are very visual people. The code can be perfect, very compact, run the machine exactly like it's meant with absolutely no bugs, but when that sensor, cylinder, valve, etc fails, what happens? A bunch of coded text is not going to help your electrical tech... They need simple ladder.
I have seen many young engineers programming incredible things, like robots to go in hazardous locations, claiming ladder was dead but failing to answer simple questions like, what brand of PLC are you using and what language are you using because there were using a unified way of programming. And that project is prone to failure because its fine and dandy as long as everything is working, but when that part fails, you will be faced with compact computer generated code and no one will be able to fix it.
Ladder existed before we programmed PLC`s, a lot of young engineers fails to understand that. It is how electrical plans are drawn and for that reason, ladder will never die as long as our machines have circuits in them.
I have also seen software programmers claiming that they can program anything, and fail miserably and financially, trying to program a machine. As long as parts will fail, you will need electrical techs, and they will always need basic ladder because it's how electrical stuff is drawn. Software programmers see network switches, cat5 and stuff that can be programmed, and think "hey, I can do that, my computer has cat5 too!".
The push for change we are seeing in our industry to put our PLC's on the internet and bring in software developers to the PLC side is because there is a race right now, and that race is called IOT.
In case you don't know what IOT is, it stands for Internet of Things, it used to be called M2M but it was rebranded. Put simple, its connecting things that are not connected to the internet right now. There is a vision for smart cities. A store coffee machine can order coffee before it runs outs, have pollution sensors on streets, automated lights, such are the claims. I myself find it funny, street lights are already automated with 35$ light sensors... but just like when personal computers were invented, the usage claims were ridiculous... "you can do your grocery list with it", I might be laughing at the next biggest upcoming revolution.
That race is huge, every sector wants to win it, Cellular carriers are in it, PLC companies, most of silicon valley tech giants, on-line stores(yeah on-line stores) and there is of course the open-source community also.
So IOT is why we are seeing all those young engineers claiming there is a disruption of the PLC world coming up, because they are told so. There are forces trying to merge the two worlds or software programming and industrial programming because they want to win the IOT race.
I use PLC's for machines, I never did batch mixing or process. So those are just my interpretations of the claims. I think this is just a case of bad design of a mixing plant and some young smart engineer that came up with a clever way to fix a problem that can already be fixed with existing technology, without upsetting too much the current programmers way of working. Then thinking that his approach is the missing link that will merge software programming and industrial programming and break an industry. The fact is, batch mixing is NOT the entire PLC/DCS industry.
The logical way to design a product, is analyzing your needs, and then choosing the right tools to achieve that. Not choosing your tools and then molding your end product with the tools your have chosen.
I presume that the specs for that plant were decided before the needs were established. Someone decided on PLC's even though it wasn't the best way to do batch mixing. But even there I have doubts, couldn't what he is doing, be done by calling subroutines with parameters? Just like in C++ when you call a function, give it variables, and it will spit out the processed variables? We use subroutines for clarity, but really it can be a very powerful tool to process repeatable code.
I proposed this to my supervisor once when he tasked me to create code for a machine we were redesigning in-house. I told him we could have one subroutine that would handle ALL the motors. We feed it tags when we call it and it spits out the processed tags. Of course he was not very fond of the idea. Not being able to go to the specific ladder and watch the rungs troubled him deeply. I explained to him that with custom tags, we could group everything related to that motor under one main tag and we could see what was going on by watching that tag, and that the HMI would have all the possible faults anyways. He was not impressed, insisted that we would have to teach all the electrical techs how this functioned. I ended up doing a subroutine for every motor. Now I can only imagine if I had asked a group of programmers to do this...
I think PLC's evolved greatly since address based programming and claiming that we program the same way we did 20 years ago is obviously coming from someone who didn't program 20 years ago. The problem is we don't use the new functionalities. We like the address based type of programming. At my workplace, when they have a machine done by an integrator, they ask for aliases to be created that mimic the address type, so that MCC6:4:I.Data.7 becomes S06_0407. Structured text is a perversion, don't ever mention those words. Add-ons are not very welcome either.
Having an electrician background, I really do understand the stubbornness though. You can visualize the electrical flow from hot to neutral when you read a ladder, and literally see where the problem is. Not the case when calling subroutines with parameters or structured text or addons, or any other way than basic ladder. This one reason why basic ladder will prevail.
Automation is fantastic a long as everything is working like intended. But when things go wrong, it's not the bright young engineer that designed the machine that will be troubleshooting the machine, it's the on-site electrical technicians, and like someone said earlier, they are very visual people. The code can be perfect, very compact, run the machine exactly like it's meant with absolutely no bugs, but when that sensor, cylinder, valve, etc fails, what happens? A bunch of coded text is not going to help your electrical tech... They need simple ladder.
I have seen many young engineers programming incredible things, like robots to go in hazardous locations, claiming ladder was dead but failing to answer simple questions like, what brand of PLC are you using and what language are you using because there were using a unified way of programming. And that project is prone to failure because its fine and dandy as long as everything is working, but when that part fails, you will be faced with compact computer generated code and no one will be able to fix it.
Ladder existed before we programmed PLC`s, a lot of young engineers fails to understand that. It is how electrical plans are drawn and for that reason, ladder will never die as long as our machines have circuits in them.
I have also seen software programmers claiming that they can program anything, and fail miserably and financially, trying to program a machine. As long as parts will fail, you will need electrical techs, and they will always need basic ladder because it's how electrical stuff is drawn. Software programmers see network switches, cat5 and stuff that can be programmed, and think "hey, I can do that, my computer has cat5 too!".
The push for change we are seeing in our industry to put our PLC's on the internet and bring in software developers to the PLC side is because there is a race right now, and that race is called IOT.
In case you don't know what IOT is, it stands for Internet of Things, it used to be called M2M but it was rebranded. Put simple, its connecting things that are not connected to the internet right now. There is a vision for smart cities. A store coffee machine can order coffee before it runs outs, have pollution sensors on streets, automated lights, such are the claims. I myself find it funny, street lights are already automated with 35$ light sensors... but just like when personal computers were invented, the usage claims were ridiculous... "you can do your grocery list with it", I might be laughing at the next biggest upcoming revolution.
That race is huge, every sector wants to win it, Cellular carriers are in it, PLC companies, most of silicon valley tech giants, on-line stores(yeah on-line stores) and there is of course the open-source community also.
So IOT is why we are seeing all those young engineers claiming there is a disruption of the PLC world coming up, because they are told so. There are forces trying to merge the two worlds or software programming and industrial programming because they want to win the IOT race.
cardosocea
Member
Siemens PCS7 does this... but the bloat is beyond belief.
Since we've touched on HMI's... Everyone says that Ladder will never go away because that is what the electrician will know how to troubleshoot. However, I can remember 2 systems that even attempted to provide usable diagnostics for a machine/system. Likewise, the manuals for some machines are cryptic at best.
Wouldn't the used programming language not be an issue if the machine actually reported what is going wrong?
It could be as simple as providing a list of interlocks for a specific function to display which is the one holding things up, or in more complex operations returning an error that can be traced back to a specific step in the program (this is quite common in PC programmers and perhaps is something we could take from them).
If a machine throws error 2003 at you and the manual states that error 2003 means that the proximity sensor XYZ did not see anything in front of it is definitely better than having the program open in front of you to decipher what is going on, isn't it?
Maybe a display of the IO map so you don't have to pick up your meter straight away?
Similar Topics
I noticed in Rockwell AOIs, they add a BOOL Output parameter at the end of the "Parameters" list of each AOI that carries the same name as the...
I have Allen Bradley plcs, I have had Circuit breakers and other automation equipment in the past.
There's no solid buyers local.
How much do you...
Hello,
I have an automation direct d2 262 plc and C-more HMI EA9T6CL-R. I need to prepare a program, scheduled to be performed on a future date. I...
Hello all- I have a unique challenge using a customers Direct logic 06 PLC. This customer has a DC motor operating at 10 RPM which is turning a...
Hi,
I have been trying to run drive via Sysmac studio. I can ping the drive. I can see the logic bits going on/off as per command. But, drive is...