Depends. Do you speak/read Chinese? Do you have an "in" with the manufacturer, or know someone who does?
My experience so far with Chinese robots has been 100% universally 
So far, every Chinese robot I've encountered has been a cheap knockoff of a Major Brand robot that is poorly made, very poorly documented, has no effective tech support, runs on crappy software, and generally shows signs of an attempt to copy a Major Brand robot without understanding anything about what makes that Major Brand robot worth buying.
Also, I wouldn't trust the safety features on any Chinese robot I've used any further than I could throw a cheesecake underwater.
The only way I would buy one of those robots would be if:
1. I bought a bunch of extras to use as replacements or as sources of spare parts
2. I hardwired my own safeties, and/or surrounded the robots with solid fencing the robots couldn't possibly punch through
3. Did nothing with them more complex than simple pick&place or spot welding.
In the interests of being fair, there may be Chinese robots out there that are better, and I've just had bad luck so far. But based on my experience with other Chinese-designed and -built systems, I'm not optimistic. There's a very consistent "amateur hour engineering" vibe in my experience, along with a frightening ignorance of even the most basic safety principles.
I usually don't care too much about spares, documentation, but would like decent software.
Well, I can only say that after ~30 years in robotics, I care very much about all three.
Does attaching cognex cameras to them and using insight software negate robot manufacturer software? It seems to me that cognex does all robotic guidance and directs the robot where to go.
Not even remotely. Adding Machine Vision (of any brand) involves an interaction between the MV system and the robot's own software. And the complexity of that interaction scales up faster than the complexity of the application.
For example, I once had a vision system that worked purely in Base Frame offsets, that the customer bought to put on a robot that couldn't support Base Frame offsets. Kludging together a solution that mostly worked was a nightmare... in no small part b/c that brand of robot had poor documentation of the details of its kinematic system and geometrical offset methods.
No MV "takes over" from the robot -- at most, the MV system takes a measurement, and passes that measurement to the robot. For this measurement to be at all useful, the robot and MV must be correctly calibrated to each other, or to some shared common reference frame. And even if the measurement is correct, it's still up to the robot to actually use that measurement in some meaningful way. And intelligently -- when I was still new at this, I didn't limit-check the vision measurements in the robot, and ran the robot straight into the floor b/c the packet data got corrupted somehow and 100.00 became 10000.
packet data got corrupted somehow and 100.00 became 10000.
I can explain the somehow:
In the USA and some other countries and also in almost all programming languages the "." is the decimal seperator.
If you live in a country where the "," is the decimal seperator, the "." will be ignored and you will get 10000 instead.
I can explain the somehow:
In the USA and some other countries and also in almost all programming languages the "." is the decimal seperator.
If you live in a country where the "," is the decimal seperator, the "." will be ignored and you will get 10000 instead.
Interesting. A single bit flip could cause this, assuming they are sending the offsets via strings.
. in the ASCII table is 46, which is 0010 1110.
, in the ASCII table is 44, which is 0010 1100.
I can explain the somehow:
In the USA and some other countries and also in almost all programming languages the "." is the decimal seperator.
If you live in a country where the "," is the decimal seperator, the "." will be ignored and you will get 10000 instead.
Nah, it really was packet corruption in this instance. It's embarrassing to admit, but this was a long time ago -- the Vision guys thought I was doing the limit checking, and I thought they were doing the limit checking. And the system ran perfectly for over a thousand cycles... until the day of the customer buyoff when that decimal got dropped in the communication channel and we learned the hard way that no one was doing the limit checking. (sad trombone noise here).
Interesting. A single bit flip could cause this, assuming they are sending the offsets via strings.
. in the ASCII table is 46, which is 0010 1110., in the ASCII table is 44, which is 0010 1100.
Huh! I did not know that, but it could handily explain what happened. IIRC, I just added a couple re-try cycles, and if the data from the vision system didn't come back within acceptable limits after 2-3 attempts, then we bailed out and summoned an operator.
in the ASCII table is 46 "."
in the ASCII table is 44 ","
And the system ran perfectly for over a thousand cycles
then this was probably not the case
You need to be a member in order to leave a comment
