On Wed, 2017-02-22 at 02:53 -0500, Gene Heskett wrote:
> On Wednesday 22 February 2017 01:51:15 Valerio Bellizzomi wrote:
> 
> > Sorry for the confusion, I meant to ask if this configuration is good
> > for running with the SPINx1
> >
> loadrt  hal_parport             cfg="0x378 out  "
> setp    parport.0.reset-time    2700
> > loadrt pwmgen output_type=0
> addf    pwmgen.make-pulses      base-thread
> > addf pwmgen.update servo-thread
> > net spindle-speed-cmd motion.spindle-speed-out => pwmgen.0.value
> > net spindle-on motion.spindle-on => pwmgen.0.enable
> > net spindle-pwm pwmgen.0.pwm => parport.0.pin-09-out
> > # Set the spindle's top speed in RPM
> > setp pwmgen.0.scale 1800
> 
> On my small mill, software step etc generation, this scale is set to the top 
> speed the spindle can turn, so is 2500. If your spindle can do 6000, yes, 6000


I am going to try this configuration when the board arrives


> > with say the scale set to 6000 rpm, it is going to work as is ?
> 
> A couple things to consider, the most important related to the order of the 
> addf's. This list is internally executed in the order encountered in the hal 
> file. So I always do the base-thread addf's first, then list the servo-thread 
> entries next just because its a bit of "organization". The actual processing 
> you are constructing is two execution loops, the base thread executed many 
> times for each pass thru the much slower servo-thread.
> 
> Haveing a module processing data from a read above the actual port read 
> inserts a one loop execution delay in processing that data, so unless you 
> want a delay on purpose, the order is always the read at the top of the list, 
> the data massaging in the middle, and the write of that data is always last 
> in the addf order. The data twiddling can be a thousand lines below all this, 
> but it will be executed in the order of the addf's. Delays in processing, 
> then making use of that data affects the stability of the loop because the 
> data is stale.  Most noticeable when setting up the PID modules.
> 


Thanks Gene for this clarification about LinuxCNC internals




> I am not using a spinx1 on that machine, but a now elderly PMDX-101 version 
> that is essentially a clone of the spinx1, but has a bunch of switches and a 
> pot so I can control the spindle either by the gcode, or totally manually, 
> forward and reverse just by flipping the switches. I do not know if current 
> PMDX cards have that same functionality or not, but at the time I converted 
> it over a decade ago, it was the most useful version extant.
> 
> It obviously cost more, a lot more as those parts were top shelf all the way. 
> The only problem I've had with the whole setup was that I blew motor fuses 
> regularly long before the motor stalled, and eventually the switching 
> transistor in the motor circuit blew.
> 
> Rummaging around in my pile of dead computer PSU's, I found a transistor that 
> looked just like it, but could handle 3x the voltage and 10x the current. 
> Using static conrol measures (its a hexfet) I transplanted one of those to 
> the motor control, added an amp to the fuse, and the blown another fuse 
> problem has been fixed.
> 
> >
> > Thanks
> >
> > On Tue, 2017-02-21 at 16:54 -0500, Gene Heskett wrote:
> > > On Tuesday 21 February 2017 12:15:22 Valerio Bellizzomi wrote:
> > > > From the LinuxCNC manual I see an example :
> > > >
> > > >
> > > > loadrt pwmgen output_type=0
> > > > addf pwmgen.update servo-thread
> > > > addf pwmgen.make-pulses base-thread
> > > > net spindle-speed-cmd motion.spindle-speed-out => pwmgen.0.value
> > > > net spindle-on motion.spindle-on => pwmgen.0.enable
> > > > net spindle-pwm pwmgen.0.pwm => parport.0.pin-09-out
> > > > # Set the spindle's top speed in RPM
> > > > setp pwmgen.0.scale 1800
> > > >
> > > >
> > > > is this sufficient to get the spindle going ?
> > >
> > > This would be for purely software driving, which generally cannot
> > > drive a machine to anything resembling high speeds when it is
> > > supposed to be making a G0 move.
> > >
> > > Thats is why the majority of us use a smart card, which in some
> > > cases can be its own breakoutboard too.  Such is the case with all
> > > but one of my machines, and that one can only move around 8ipm
> > > cutting and 10 or so at full throttle. My stuff with more std
> > > interfaces can move 40 to 75 ipm without missing a beat.


I'm not accustomed to inches, that should be 40 * 2.54 = 101.6 mm/min

with my current machine I can set a speed of up to 800mm/min (when
cutting wood) without any problem

I just make sure the spindle speed is ok so that it doesn't burn the
wood


> > > Also associated in the speed limits are the limited drive currants
> > > available from the parport. Getting 10 mills out to drive the
> > > stepper drivers doesn't turn on the opto's all that fast, so that
> > > contributes to the speed limit. Most of the accessory boards can
> > > sink 24 mills, easily turning the led on in the isolation circuitry
> > > of the driver.
> > >
> > > But the most telling in using a parport with direct drive is the
> > > pulse jitter, as indicated by running latency-test for half an hour
> > > or so. Every time you see a spike/raise in the displayed time of the
> > > base-thread, thats a long step, and the motor may well stop while
> > > waiting for the next step, but when the cpu, even running an rtai
> > > kernel, will then try to catch up when it does get free of whatever
> > > it was doing, but the motor isn't able to re-accelerate that fast so
> > > it stalls.  And everytime it stalls, you have a damaged or wrecked
> > > part.
> > >
> > > That makes spending the sheckels for a smart card interface very
> > > much desirable. If that interface can also be the BoB, thats a
> > > desirable economy. There are several mesa cards that meet that
> > > criteria, and I'm fond of the 7i90HD, which gives you a big pile of
> > > very steady heartbeat signals, as high as 8 stepper drivers, 4 pwm
> > > generators, and 4 encoder inputs.  What you do not use, can be
> > > removed from the load
> > > configuration, and those pins then used as General Purpose I/O, for
> > > a grand total of 72 of them. The 7i90 can be driven by a std EPP
> > > capable printer port, (yours may or may not be EPP capable, and
> > > mainboard manuals do not always state the truth) or by an SPI port.
> > >
> > > So please reconsider how you are going to interface to the
> > > machinery. Getting some isolation between the computer and its
> > > jitter pulse generation is something you'll never regret.
> 
> Ping?
> > >
> > > Where on this ball of rock and water are you?
> 
> 
> Cheers Valerio Bellizzomi, Gene Heskett



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to