On Wednesday 17 January 2018 11:10:53 Nicklas Karlsson wrote: > On Wed, 17 Jan 2018 09:27:25 -0500 > > Dave Cole <linuxcncro...@gmail.com> wrote: > > The text below is at the end of the SOEM page from the link below. > > https://openethercatsociety.github.io/doc/soem/index.html > > > > So how does this work?? The SOEM software itself is GPL, but if > > you implement an Ethercat master, you need to get a license ?? > > Why a license? > > I have nothing about sharing my work but copyright issues i something > different. > > Then in european union I read something about interoperability so you > are always allowed to make your own device to talk to other device. > > > That's an interesting approach. > > > > If the SOEM code is all GPL, then how could adding GPL code to GPL > > code result in something other than GPL code ? > > > > From a practical standpoint, I think we need to figure out how to > > get networked drives connected to LinuxCNC if we want LinuxCNC to > > live on. At some point analog servo drive interfaces will become > > like 5 1/4" floppy drives... They were once common. > > Yes. > > Michael Büsch already implemented a profibus master. I have it running > against an IO module and millions of these kind of devices have been > sold. I think he implemented on Rasberry and I had some timing issue > before running on ordinary computer but have not looked further > because I have been busy with something really good for servos and > looking for a new woman. > > Bandwidth required to replace an analog signal may be surprisingly > high and for a control loop even though there are plenty of bandwidth > it need to split in many small messages. Ethercat solve this problem > in a similar way as cascade coupled shift registers. > > > Nicklas Karlsson > I think this might be right up PCW's alley. He is already selling some cards that expand via an rj45 jack. Perhaps he could chime in here as to the advantages and disadvantages of adapting the firmware to be something like this, but call it something other than ethercat.
Changing the subject a bit while I ramble, we have some amazingly cheap rs485 devices about, costing less than a buck each in bags from ebay. These can be full duplex, and rows of them could be made on a breakout card, all we need is an effective chip selection mechanism. I recently used a pair of them as the receivers for an encoder with differential outputs by disabling the transmit function. They are outputting quite square waves to the A/B inputs of a 5i25, with a 1000 line encoder spinning in the 8 to 10k revs region as the encoder is on the rear of that 1hp, 90 volt rated, motor while the motor is being fed around 123 volts. I figure I am getting more than 1.5 hp out of it. With the OEM triac based controller, it turned the spindle 2200 revs. With this lashup, 3k is usable for 2 minutes as there seems to be a thermal switch in the motor armature, (but the motors heating cannot be detected) and 2750 forever. There isn't any reason a bunch of these couldn't be associated, one to a servo axis, and I don't think they would be a bandwidth problem doing it. All we need are the interfaces ( more of these facing the cable ) and whatever servo driver is to be used, Jon's pwm-servo comes to mind, mainly because I've found it quite usable as spindle controllers on my smaller stuff. PMDC motors up to 2 hp are right in its bailiwick. This is a case of doubleing the speed of my G0704 when I replaced the intended for mach use BoB on it with a SainSmart BoB, also intended for mach, getting rid of all opto-isolators in the the output paths. I had to bypass them for the two inputs I used for the encoder because they quit functioning at about 400 motor rpms, opto's wwaaaaaaaayyyyyyyyyy to slow. But getting rid of the slow opto's in the step/dir paths has allowed me to cut at least a full microsecond off the step driver timings, I am still experimenting with that, and the nice clean pulses to the drivers has taken me from 55 ipm without stalls speeds to 110 ipm w/o any stalls, includeing the z motor while lifting that 50+ pound head, with max_accel's in the 140 range. Just a bump and the table or the head is now moving at 110 ipm. These motor drivers all have their own much faster opto's for that, so use them. The difference in speed is the SainSmart bob and its lack of opto's in the output pins. I did find, finally, the reason for the extremely letharic accel's once homed. Linuxcnc will complain about missing AXIS_L limits and refuse to start, but not about missing [AXIS_L] MAX_VEL or MAX_ACCEL in your config files. IMO it should, but doesn't, it just kills the machines performance. Shame on LinuxCNC. I thought the conversion to JOINT_N nomenclature was complete but it is not, so yesterday while reading the docs and finding those two vars were still listed under the axis heading, I put them back in the ini. Problem solved with a vengeance because I had turned much of the traj and joint settings up to no visible effect, but I have yet to put a dial on things and verify no stepper slippage at the much improved speeds the SainSmart bob allows me to use. I also found the PSU driving the XY motors has drifted down in output voltage, to around 36 volts, but haven't managed to get to that pot and turn it back up to around 42 volts. Using these buck a copy rs485<->ttl gizmo's would be ideal to drive a long cable carrying a pwm signal for a servo, using a pwm clock fast enough its effectively an analog circuit in terms of bandwidth by clocking the pwm at 10 kilohertz. And you could do it over a twisted pair as long as needed to get to the motor controller. The motor would need an encoder of course, on a 6 wire cable coming back, round cat5 is cheap in stranded for motor movement flexibility. Should outlast the cable chain its in. And all we'd need was the com protocol to address each one in the bob, and in the firmware for the mesa cards if its not already there. The 7i90 for instance can do 4 ea of stepdir, pwmgens, and encoders and has sufficient i/o pins to double that, while still haveing plenty of gpio to diddle other things. I've enabled all the stepgens and encoders and two of the pwmgens because of blown gates from the noise pickup when I was trying to build all the electronics in the same rusty old box the motor drivers are in, but a separate box for the pi, the 7i90, and the 7i42TA's has solved that noise problem completely. /ramble off. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
