Good day All,
Just thinking out of the box...Given that there is an interest in developing better software for the N4, what if someone approached the fellow who designed and developed his own PnP called VisionBot (http://visionbot.net/) and perhaps convince him ($) to port his software to support the N4? This might be a viable approach if his software is solid, etc... and it does look fairly mature.
Cheers,
Sam
Hi
Inevitably there is a certain amount of "secret sauce" in the firmware inside a pick and place. For better or worse, there is no standard interface language to talk to these beasts. You need a bunch of information from the hardware / firmware guys first. You then need to check that over (validate it). Often there are things in the information that simply don't work quite as described. (quick note --- I don't know anything about the Neoden firmware. I do indeed do this for a living). Once you have that, the guy on the other end needs to have a chance at looking it over. Without seeing the way they did there "stuff", he has absolutely no way to know how hard the process will be.
At this point he can give you a quote on what it's likely to take to do a port. He comes up with an estimate (say a year's work) and you hand him the first installment payment. He now needs a Neoden 4 and some parts to thump on as he does his thing. He also needs a line to the guys at Neoden. The "hey Bob, this thing you wrote doesn't work the way you say it does" conversation will take place a *lot* of times (like a few times a day) for the first few months. Since this is a retrofit, you will be fixing firmware bugs in the driver code rather than having the firmware guys do the fix.
So now you hand him his final check and he gives you a piece of code. Just like all the other stuff, it's about 90% there. (It's always only going to be 90% of the way). Out it goes to the field and in come the bug reports / upgrade requests / feature mods / support questions. Taking care of all of that *is* a full time job for somebody. In fact it's probably a full time job several guys. He politely requests *more* money to do that for a year than the original software cost to port.
Net result, you now have a company. It has running costs and a workforce. It pays taxes and has a web site. It needs a regular income to keep all of that going. Hmmm.....
Bob
Good day Bob,
You are quite right... I was just suggesting another option. That being said what are your thoughts and/or direction options?
Cheers,
Sam
Hi
I think one *practical* way to do something like this is to have an open interface standard. Something the "hardware guy" can build to and verify against. Multiple outfits all use the same this or that command to do the same thing. You have a descriptor table somewhere in eeprom or flash that gives all the details of what is what. This is basically the way things like USB and Bluetooth work. The guys on the "other side" can then go write code that works against the standard.
Using USB as an example, you quickly find that it is rare to have a driver for this or that device come out without it being done by the people who made the target gizmo. Indeed third party drivers *do* exist and that validates the whole scheme. If you dig a bit deeper into USB, you find that the mothership (usb.org) charges various fees and issues licenses for this and that. Setting up an organization to administer something like this for pick and place .... not likely to happen.
That gets you back to a three way deal. Some sort of user group funds a process. There are contracts with various people. Doing some math:
Developer guy gets $120K a year and takes a year, gets same per year after that
Equipment and software for compatibility testing runs $20K to $60K a year
Two support guys get $60K a year after the first year.
Somebody manages all this and gets $120K a year.
You have about $200K in the first year and about $400K a year after that. Before you go off on the numbers, try setting up and paying all the taxes, utilities, mandatory benefits and the like on a group of people.
So to fund that, how many people own one and are ready to pay a yearly support fee?
If it's 1,000 people ... you each owe $400 a year. If it's 100 people, you each owe $4,000 a year. Consider that this is support contracts and not machines. You inevitably will have people with multiple machines who will not expect to pay on a per machine basis. Your support costs do not go up by 8 when Bob has 8 machines, so that is a reasonable assumption.
So what happens? You start with the assumption that you will get 1,000 people. You charge $400. You get 121 people ... end of project.
How was it done initially? They paid the guy his fee for initial code. The machine he worked with was a prototype they already had. The 120K gets spread out over a run of a couple machines a working day for the first year. It's an incidental expense spread out over 500 to a thousand machines.
We don't see it from "our end" of the pipe, but the price of these machines goes down on a monthly basis. The one here / two there sales are not what keep a company afloat. It's the guy who wants 10 or a hundred machines that really sets the market. He may not be an end user, he could be a dealer. It's a good bet that whoever it is, the price just keeps going down. That's why the software gets done up front and there isn't any money later on.
This is why decoupling software support contracts from machine sales is a really good idea. You buy your machine for price X and it comes with support for a year. Past that, you pay a fee (and have some level of expectation about support). Inevitably your expectation is a bit higher than what gets delivered but you pay the "ownership tax" to keep things going. Essentially what the costs at the top of this are looking at is the real sort of fees and costs associated with even a "bare bones" approach to that.
Bob
Home
Help
Search
Login
Register
