Keith said...
"The original thread indicated 5 METERS between stands..."
If that is what it said in the orignal thread, not any posts in this thread, then, I don't recall seeing that spec.
You gotta know, don't cha(?), that it was truely hard to read that guy's posts. It was hard to glean any details at all while "listening" to all the weird-speak, and seeing the weird video inserts.
I mean, gee whiz... Phil deleted the thread! He didn't just LOCK it, he DELETED it! It was a literal assault on our sensibilities! Even Phil thought so!
So, my point is, I don't recall all of the details. I only know that there were few. And then, with that 100 meter-per-second thing... then I blew it off totally in terms of the particular poster.
But, in general, he did give me an interesting problem to use to explain Roll-yer-Own. And so, in as simplistic a way as I can develop, I'm going to use that problem to explain the general concept behind Roll-yer-Own.
Peter...
As I said, I'm going to use very modest constraints to ensure that there is no critical time limit situations relative to devices that monitor/control the process. Basically, and simply for the sake of describing the process necessary to control this situation, I'm going to push critial device timing issues aside by simply using very modest constraints.
And, by the way, in as much as you did the same, I already conceded that we are going down the same path. However, maybe for different purposes.
The idea is to present, for those that don't know, the Roll-yer-Own Method.
At this point, I'm only interested in presenting the basics of motion control without being subjected to the inherent limiting factors that become very apparent with some devices in time-critical problems.
That is... Here is a set of constraints. The constraints are well within the specs of the particular processor and subordinate devices. Here are the tools that you need to make this work!
Peter said...
"So how do you tell if an application can be done? I have customers asking me this question all the time as if they want some guarantee the motion controller can cover for all their problems."
First of all... those "customers" are poorly educated... whomever they are! I put the quotes around customers because... in too damned many cases... the "customers" are some management pukes that haven't got the slightest clue as to what is really necessary. Of course, those idiots tend to control the expenditures... but they are still idiots!
They are shooting from the hip, and they are shooting in the dark!
It is easy enough to prove, in terms of its' load, whether, or not, a particular PLC processor can handle the particular problem.
You, of course, are interested in selling your control modules. More power to you! However, customers must realize that YOU (Delta) would not be serving your own self-interest to show a potential customer that it is, infact, possible for his particular processor, under its' particular load, to handle a particular problem.
However, if it is proven that the PLC can not handle the problem, within the appropriate margins, then... your controller should be subjected to the same tests that excluded the PLC from being able to handle the problem. If your controller passes those tests, again within the appropriate margins, then you've got (or should have) a customer!
If your module doesn't pass the test, is the customer is asking for Pie-in-the-Sky? Or is that his request is reasonable and your product is simply not upto snuff (or would that be "s'nuff"?).
If the customer is going for Pie-in-the-Sky, then maybe he simply needs to be reined in and made aware of the Laws of Physics. If not, then your product needs to be updated.
That's simply the way it is - one way or the other. But then, in reality, if you find a customer asking for something within the Laws of Physics and yet beyond what your product can provide, your "canned answer" to that customer is... You are asking for Pie-in-the-Sky! Of course, at that point, the customer's expectation is Pie-in-the-Sky only with respect to your product.
If you are the absolute leader in that field then the customer is stuck.
If you are not... then the customer has options. Sure, there are cost issues for the customer... but then, that is for the customer to decide.
I can very easily see that it doesn't take much to prove whether or not your control module can work, or not. In the world of PLCs, it's all, and only, a matter of process, processor, and subordinate device, timing issues.
But then, in the final analysis... it all really depends on how your control module is programmed by... you, or the local-Rep, or the local Integrator (yuk*) or the local on-site guy!
(yuk*) The local Integrator is typically like a night-bomber... in-and-out... job done, gone and forgotten. I KNOW... I'VE DONE IT! And I've HATED MYSELF for doing so! So don't try to snow me on that ****.
The real key is the on-site guy. He is there, he has to live with it. He sees what is going on from day-to-day. What does he know? How capable is he in terms of your product? How capable is he in terms of... generally speaking, process control and process development?
If YOU (Peter, or one of your guys) doesn't do the right thing in terms of the real process issues (rather than that damned "good-enough" deal) then... how well is the customer and his problem really served?
Enough... I think I made my point... and then... more than enough!