Chris Radek wrote:
There are lots of ways encoder hardware can
detect problems: invalid quadrature transitions, extra or missing
counts between indexes, and maybe more. If the encoder hardware knows
pulses per rev (which is not the current scale value it knows) it can
detect missing index
EBo wrote:
I could see having that functionality as a compilable/loadable
diagnostic test so that it would not have to run all the time (ie saving
CPU cycles). I like the proposed functionality.
I actually have this test in some of my diagnostics. They set up the
encoder counter to
I have a customer wanting to use a jog pendant to change the feed and
spindle overrides, as well as do jogging. I know how to do the jogging
part,
you feed the scaled MPG to axis.n.jog-counts and enable the desired
axis with axis.n.jog-enable.
How do you change the feed and spindle overrides,
Sebastian Kuzminsky wrote:
On 01/04/2012 08:20 PM, Jon Elson wrote:
I have a customer wanting to use a jog pendant to change the feed and
spindle overrides, as well as do jogging. I know how to do the jogging
part,
you feed the scaled MPG to axis.n.jog-counts and enable the desired
axis
Chris Radek wrote:
On Wed, Jan 04, 2012 at 11:59:36PM -0600, Jon Elson wrote:
Definitely do not want it to jump to a position related to the current
jog encoder position.
This is why there's always an enable corresponding to inputs that take
counts. You just need to hook it up
OK, one more thing in the same vein,
The user wants a feed hold toggle button. The HAL component toggle is
perfect for the push-on/push-off feature, but how do you implement this?
Is there a feed hold input to motion (or whatever)? I looked around a
bit and didn't find such.
Thanks,
Jon
sa...@empirescreen.com wrote:
This is how I understand it. Emc only looks 1 segment ahead for blending.
(I think cutter comp may look a little further for checking on gouging but
that is just a feeling)
Right, that has been my understanding. But, I ran across the comment in
the user's
andy pugh wrote:
On 7 January 2012 02:17, Jon Elson el...@pico-systems.com wrote:
You've already heard from Mesa, Pico Systems also has the Universal PWM
Controller
Yes, Sorry Jon. I normally try to mention both, and Motenc too. (I
think we have agreed to deprecate Pluto
Jeff Epler wrote:
On Thu, Jan 05, 2012 at 10:37:35PM -0600, Jon Elson wrote:
I just had somebody ask me about contouring performance of EMC2.
I spotted something in the user manual I had never seen before, section
3.1.4, that says that no move can ever go fast enough that the machine
Len Shelton wrote:
I have witnessed on many occasions on several of our own machines and
from many of our customers what would appear to be a dropping of the P
parameter on G64 causing rounded corners on all corners, except the
corner at the start and stop point.
This happens at some
I was just perusing some of the EMC docs, and wound up on the PID
hal component docs and source. I have never quite understood the
behavior of
the D term.
To (over) simplify:
error = commanded - feedback
errorD = error - previous error
output = error * P + errorI * I + errorD * D
Let's look at
Karl Cunningham wrote:
I assume from your results there is a typo in the feedback -- it should
have been 4.9 this cycle and 4.8 last cycle. So
Terribly sorry, YES, that is what I MEANT to type!
If I'm missing the boat, please let me know.
Maybe I'd better refrain from doing even SIMPLE
Kent A. Reed wrote:
---
Pico PPMC Driver (drivers/pico_ppmc.html)
It's a minor nit, I know, but it seems to me the different Pico-board
designators PPMC, USC. and UPC should be mentioned in the introductory
paragraph since those acronyms show up repeatedly in the technical
description.
I was just going to do some LinuxCNC renaming in the Wiki.
I find the entire wiki seems to be set to read-only.
Also, a number of pages seem to be missing.
In Getting started:
Supported Hardware, Installing Linux and LinuxCNC pure
simulator are not active links.
In configuring LinuxCNC / Servo
Alex Joni wrote:
I was just going to do some LinuxCNC renaming in the Wiki.
I find the entire wiki seems to be set to read-only.
If it's read-only, then you are not signed in.
See: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BasicSteps
OK, apparently one needs to reset their passwords
Jon Elson wrote:
I was just going to do some LinuxCNC renaming in the Wiki.
I find the entire wiki seems to be set to read-only.
Also, a number of pags are still missing.
Table of Contents / Getting started:
LinuxCNC Supported Hardware
LinuxCNC Installing Linux
LinuxCNC pure simulator
Kent A. Reed wrote:
This is the problem of legitimately (in the sense of that's the way the
Wiki works) broken links I noted yesterday in my message Wiki editing.
I haven't seen any responses that suggest I and others shouldn't just
forge ahead to (re)construct the connections.
Well, the
Jeff Epler wrote:
linuxcncrsh [the program we're talking about now]
tklinuxcnc [the Tk-based GUI]
If we were to shorten them up, maybe it should be cnc in command names
(xcnc, cncrsh, tkcnc).
Those look good to me, the ones above ARE getting a bit long.
Jon
Stuart Stevenson wrote:
Gentlemen,
Wichita is always available. If we can get a consensus on a
date/period we can schedule it.
thanks
I'd certainly come! It is closer than Ann Arbor or so to me.
Jon
--
Keep Your
EBo wrote:
who's joking ;-)
Actually, there are some low-powered SOCs that run Linux, and if any of
them can be made to run LinuxCNC nee EMC2, it would be replaceable. If
you poke at this please let me/us know...
The BeagleBoard is a good candidate, about 2W with an SD card for
disk,
Kent A. Reed wrote:
On 1/25/2012 10:56 PM, Jon Elson wrote:
EBo wrote:
who's joking ;-)
Actually, there are some low-powered SOCs that run Linux, and if any of
them can be made to run LinuxCNC nee EMC2, it would be replaceable. If
you poke at this please let me/us know
Kent A. Reed wrote:
I was just hopeful because of your last line No RTAI so far, but that
might come soon.
Well, Torsten Koschorrek tells me he is STILL working on the port. Must
have been WAY
harder than he originally thought. I would have expected that the
BeagleBoard has such
wide
Hello, all,
I have just discovered a bug in the 2.5 hal/drivers/hal_ppmc.c driver.
There are several
optional features that are activated by options on the loadrt line.
These are the extradac=0x00 and the timestamp=0x00 options.
They appear to work separately, but when they both appear on the
Kim Kirwan wrote:
Hi Jon,
A UPC board, this is a Universal PWM/Servo Controller?
So a PPMC setup would not be of any help on this problem?
Just trying to offer help if I can, but no UPC here.
Nope, a PPMC doesn't have the spindle DAC option, and at least so far
I have not added the
Sebastian Kuzminsky wrote:
The long if/elseif statement that begins on line 635 seems wrong to me.
If need_extra_dac is true, then the following else if statements won't
be checked, is that what you want? Shouldn't they be independent, with
the need_* dependencies checked explicitly at
andy pugh wrote:
On 29 January 2012 04:50, Jon Elson el...@pico-systems.com wrote:
If you request both extradac and extradout it gives a specific message for
that from line 637.
Is the problem that line 642 is an 'else if', so isn't run if any of
the other 'else if's are true
Right, the other two options are mutually exclusive, so an else if is
appropriate.
The timestamp is not SUPPOSED to be mutually exclusive, but this code makes
it so. Thanks!
Thanks, guys! Sometimes you can stare at a problem, know exactly where
the trouble is,
yet not see exactly what
On the News page of the LinuxCNC site, it shows a release date of
23 March 2011 for BOTH 2.4.6 and 2.4.7
There is no listing for 2.4.5
Is this a typo?
Jon
--
Keep Your Developer Skills Current with LearnDevNow!
The most
John Thornton wrote:
I have to disagree with this, you can have unlimited INI options if
you call them from your HAL file and as we all know this only confuses
new users when they see a snippet in the manual and assume that it is
used by LinuxCNC in some way other than how it is used to
Mark Haynes wrote:
For recording movements at every 1/2 second intervals is the g-code file that
you play back consist of a new line for each 1/2 second? So that every line
of g-code is a x,y,z, and feedrate value for that 1/2 second interval. If so
I think there would need to be some
Spiderdab wrote:
I'm sure with my pc i can have an higher recording rate. The problem is
that when i've tried to record every 1/10 of sec doing rapid 3D
movements (let's say 1 m/s) the curve is recorded in little lines (one
every 1/10s..) so when i reproduce the movement, the system cannot
Spiderdab wrote:
Yes I've tried using G64, but maybe i didn't know how this worked.
because i didn't have the expected resulting.
Just because you mentioned, is it correct to use such a line at the
beginning of the g-code file:
G64 Pp Qq
in which p is the maximum distance admitted from the
Spiderdab wrote:
It is G64.1 Pxxx. G64 turns on some smoothing, G64.1 turns on more (and I'm
vastly oversimplifying it.) Well, maybe they have changed it, but I'm
pretty sure
I used G64.1 Pxxx, but looking at section 3.1.3 it doesn't say that.
Michał Geszkiewicz wrote:
W dniu 14.02.2012 14:28, Spiderdab pisze:
and, I really cannot understand what Q does (naive) and if you have to
use Q together with P or without.
P value is maximum deviation of path allowed.
Q value:
let say we have two parallel continous lines. we have
Spiderdab wrote:
Thanks for this explaination. in my case i'll have only line-line
movements, since the way that i'm recording movements is point-by-point.
so i don't have need of Q.
speaking for absurd...what if (talking about mm units) i exagerate the P
value to..let's say 1000 mm, in a
Viesturs Lācis wrote:
Or even better You could ask Jon to share his test file and see a
working implementation of G64 Pxx command.
My test file is at http://pico-systems.com/codes/contour.ngc
it is 10,000 G1 vectors that do a 2.0 diameter circle at a feedrate
of 30 units. You might want to
andy pugh wrote:
I am not sure about that, I seem to recall reading here that it will
still touch at least one point of each line segment.
Activating the naive cam detector with Qxx (IIUC) will actually remove
some line
segments, if their deviation from a straight line is less than the
Mark Haynes wrote:
Can someone please explain to me the development process for LinuxCNC? Is
there a project lead, or is LinuxCNC developed by the entire community? If I
create a new feature that I would like to see in the LinuxCNC software, how
would I go about it getting published?
It
Viesturs Lācis wrote:
2012/3/13 Brad Murry bradod...@hotmail.com:
You would be able to setup a nice linux box tuned for EMC and then access it
from another linux machine, a windows PC , tablet or even a smart phone
potentially.(smartphone control pendants would be excellent)
Hmm,
Lee Studley wrote:
Anyone use VMware under windows host to run LinuxCNC development. I'm
really interested in you thoughts as I setting this up.
I've done it the other way. I run several CentOS (Linux) systems on the
physical
hardware, and run Win 2K as a guest OS under VMware. This is
Kim Kirwan wrote:
With 12.04 and 2.5 waiting in the wings, and with new UI's
and similar such as GladeVCP, ngcgui, etc., not to mention
the disappearance of 4:3 displays in favor of 16:9 or 16:10,
I would like to pose a question for the developers:
How long will 1024x780 remain a viable
Hello,
I have a project that is not related to LinuxCNC, but looks like it is
closely aligned with Glade and maybe Python. I hope list member
son;t mind the digression.
I have built some control GUIs in the past with Tk/Tcl linked
to C++ programs with swig. These were purely control, they
Chris Morley wrote:
John did you see this tutorial?
What tutorial?
It is a little out of date.
It talks of converting the xml file. There is no need anymore.
I already did some work with the 2.12 version, which generates C code
to interface with the GUI. It almost works, but I haven't
Chris Morley wrote:
John the tutorial I was looking for is so out of date it would not help.
using glade that actually makes code is REALLY old - don't do it!
Right, I was playing with it mostly to learn how to build the GUI.
I am going to try to get my desktop system updated with a newer
Dave wrote:
Jon,
Parts of this tutorial may be helpful.
http://www.micahcarrick.com/gtk-glade-tutorial-part-1.html
Thanks!
Jon
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
Kent A. Reed wrote:
Jon:
Straying even farther off topic, what are you running on your BeagleBoard?
Matt Shaver set up a Debian-derived system on the Beagle a couple years ago.
I updated it one kernel rev so I could use cheap Chinese USB-Ethernet
adapters.
I actually am not sure what
Saccilotto Fabian wrote:
Hi Michael,
thank you for your fast reply.
I never used Emacs really, do you have any good source of a manual?
The simple stuff is really quite simple. ctrl-x ctrl-s writes out a
file, leaving the editor
running. ctrl-x ctrl-c closes the editor, and asks if you
Dave wrote:
The back end of that tutorial link I sent, parts 3 and 4 have an example
of linking the Glade3 results into a C program.
http://www.micahcarrick.com/gtk-glade-tutorial-part-3.html
If you find a better tutorial than the Micah Carrick one, let me
know.That was the best I
Anders Wallin wrote:
2) How portable is the real-time code (ie: can it be compiled for Arm
or PowerPC)?
LinuxCNC uses the RTAI kernel/API. There are a number of architectures
listed here https://www.rtai.org/
I don't know if anyone has made LinuxCNC work on other than x86 and x86_64
Kirk Wallace wrote:
For instance resolvers were not supported until some of
the developers got machines that had resolvers.
Resolvers are not supported by LinuxCNC at all, as far as I know. They
are handled by several vendor's adapters that produce what appears to be
a traditional quadrature
Yishin Li wrote:
The reason that I have not deny this comment is because we do not
have a platform to verify this with our USB/FPGA control board.
OK, good, I couldn't imagine a fundamental reason why it shouldn't be
compatible.
We are thinking of setup a platform to verify Rigid Tapping,
Yishin Li wrote:
I've added the JERK to Rigid Tapping. The detail modifications are at:
https://github.com/artek/emc2/commit/6bbdad2a001f4d129d117aa75d1dd3558401bdf2
It passed the rigid tapping simulation, although, I think the behavior
is a little bit odd for FINAL_REVERSAL.
If it starts
EBo wrote:
Have you tried any ridged tapping in aluminum? Might break a few taps,
but it would be worth testing out and demonstrating.
An easy check before risking any tooling is to do the operation in air.
Possibly illuminate the tap with a flashlight to eliminate perceived strobe
Michael Haberler wrote:
I've threatened to do this, and since it is slowly moving towards master, I
thought I'd reduce the surprise factor by laying out plan and status
Wow, impressive list! Run from line sure has some deficits, so any
improvement
in the reliability of that seems good. I
Florian König wrote:
hi,
i want to use linuxcnc with my proxxon mf70. I still looked at the
wiki but i also want to ask here, perhaps the hardware-wiki is a
little bit out of date.
What is a good (good supported) controller-interface (pci-card, usb,etc) ?
What are good motors to use for
Michael Haberler wrote:
I've rethought this a bit. Since I am working on and off on refactoring
interpreter state into separate classes (modal state, execution state, world
model, config) it would be a relatively small step to modify the current
approach of directly setting/getting
Kenneth Lerman wrote:
I guess your style is more subtle than mine.
I think I would just record everything whether or not it changed.
Hmmm... if we store 1000 bytes at each step for a million (executed)
line program. That's only a gig. Small potatoes by today's standards.
Remember that
John Morris wrote:
If the rt-preempt route doesn't work, I'll try applying RTAI to a
kernel RPM. It would be neat to get LinuxCNC working with linux-rt,
of course, but from what I've found on the list and the irc logs,
there's only a small amount of interest ATM, though that might
Michael Haberler wrote:
in following the venerable tradition if everything else fails, look how
Fanuc does it:
My Allen-Bradley 7320 (a 1978-vintage control, 16-bit minicomputer) had
a jog retract
function. You could interrupt a move in the middle of the move by
pressing cycle stop,
then
Viesturs Lācis wrote:
2012/4/27 Dave e...@dc9.tzo.com:
It is not written to in that case.. IE it is not assigned a value.
Sorry, but I think that there are 2 options - either it is 0 or 1.
Your answer seems to indicate that there is third option. Or is it too
much beer for one
Yishin Li wrote:
We don't have a spindle in our Lab. We've quoted a 80-mm motor spindle
with encoder for position control. However, it costs $3500, which is beyond
our budget.
What kind of spindle is required for verifying above tests?
We'd like to know the most economic ones.
Or, we would
Yishin Li wrote:
Michael has provided us a spindle simulator for this purpose. It really
helps.
However, we still like to get a *real* one for rigid tapping ;-)
Oh, OK, I think by viewing signals in Halscope I could be pretty
confident it is
working correctly. But, in the US we
Joachim Franek wrote:
On Wednesday 02 May 2012 11:56:30 Anders Wallin wrote:
http://www.anderswallin.net/sandbox/trajectory.jpg
Are this calculated or measured spectra?
The spectrum is so full of noise all the way up and beyond the range
of the chart, that it has to be measured
Viesturs Lācis wrote:
Anywy the servo period length can be adjusted as well. I
myself have set servo cycle at 1,5 kHz on D525MW based PC. I have read
that other users have achieved even better numbers.
I have run at 2 and 4 KHz. 2 KHz is easy, with my parallel
port-connected hardware,
the
Joachim Franek wrote:
And I am not sure what was measured. From this motion
profile (0.1 to 0.2 s time to reach max. velocity)
I do not expect frequency components in the
800 to 1200 Hz range.
Right, I think this is a bunch of noise from the servo drive, motor,
encoder,
etc.
Another
EBo wrote:
Hmmm... it would be nice if there was some way to sense the signatures
and dump enough meta-info to then do some analysis to ferret out what
the root cause might be. To many ideas... not enough time...
By running the machine at different speeds, you can sort out some
Anders Wallin wrote:
If someone really wanted to get into this on a hobby level there might
be acceleration-sensors (made for e.g. airbag-triggers on cars) which
could be used?
Simply HAL-scoping commanded/actual position and maybe looking at
their spectra might be a good start too.
Years
Michael Haberler wrote:
Am 03.05.2012 um 13:15 schrieb John Thornton:
Is there some reason that the MDI window can only have one line of code?
Every CNC control that I've touched (3 or so) allow you to enter as many
lines as you want in the MDI window.
There's no conceptual
EBo wrote:
Just brainstorming
here, but could it be used as a tool to help tune a machine?
Yes, definitely. Some of the lower frequency stuff could be extracted
with Halscope
dumps.
Jon
--
Live Security
EBo wrote:
Yes, those projects are uber cool, and I am familiar with some, but not
all, of the tools you mention. My real point was it would be REALLY
cool if EMC/LinuxCNC has these analytical tools in its arsenal. I
would LOVE to be wrong, but I do not remember hearing anything about
Karl Cunningham wrote:
On 05/04/2012 07:26 PM, Jon Elson wrote:
You'd need a swept
sine wave generator to stimulate the system, and record the response of
the system, both amplitude and phase to the stimulus. Just add the sine
wave excitation to a constant position and feed
Karl Cunningham wrote:
If this can be made to work, it's possible these techniques could also
be used to help tune PID coefficients. Or at least point out where there
is marginal loop stability.
Absolutely! A Bode plot of gain and phase vs. frequency tells everything
about loop
Jan de Kruyf wrote:
This is very good off course. The lowest figure I have heard in the CNC
world is 500Usec. But that I would consider nonsense for the market LCNC is
operating in. 5 millisecs servo looptime is ample in almost all cases.
I have run my parallel-port attached hardware up to
Kent A. Reed wrote:
For those of you following the RTAI on ARM discussion, I just stumbled
across a primitive porting guide that Torsten Koschorrek posted to the
RTAI repository in March of this year.
Who knows, he might actually do the cleanup and patch work. He might
even scratch Jon's
Jan de Kruyf wrote:
Jon:
when I started working in the CNC field we had 20msec loops and they
worked(cutting steel) from pure fanciness we would upgrade to 10msec, and
with a well tuned servo drive you could feel the distinct steps of the DAC
while accelerating.
Yes, with velocity servo amps
David Armstrong wrote:
would anyone concider this approach feasable
http://code.google.com/p/miniemc2/ then attach a fpga sub board similar to
the mesa 7i43 perhaps for a fully contained web browser style application
I see some problems. Only 64 BM of RAM, and only 400 MHz. The Beagle
EBo wrote:
On Fri, 18 May 2012 18:42:53 -0700, dave wrote:
Matt and I were talking the other day about a next-gen linuxcnc
processor and wandered into the area of a decent processor coupled to
an fpga for all the stuff that a normal processor doesn't do well.
have you taken a look
andy pugh wrote:
On 31 May 2012 12:19, Michael Haberler mai...@mah.priv.at wrote:
I think it is about time this community considers and decides what to do on
RT network I/O devices - a plethora of special-case contraptions is
undesirable IMO.
I see a mention of a Realtime
Dave wrote:
I see that Jon Elson will be at the CNC Workshop.
As far as I know, Matt Shaver and Steve Stallings will also be there.
Matt knows a LOT about the Smithy situation, if you buttonhole him,
he can tell you more than you want to know.
Jon
gene heskett wrote:
To start with mosfet/hexfet's have one very non-endearing feature. Because
they are effectively the perfect equivalent to a vacuum tube triode, they
also share a attribute known as miller effect in the tube world. This
makes them look as if there is a large capacitor
gene heskett wrote:
Your idea of triple chipping the driver is an excellent one, but needs a
storage capacitor directly across the chip(s) supply pins, 2 of pcb trace
away won't cut it. Its got to be right there on those 2 pins, and a
capacitor per chip is probably a very good idea.
Yes, I
gene heskett wrote:
Yes, I put a 1 uF cap on the back of the board directly under the driver
chip. One for the
low-side driver and logic, one for the floating high-side driver. I've
been using this general
topology since 2004 or so in my brush servo amp designs.
Jon
Sounds like
jeremy youngs wrote:
jon due you have a schematic and bom? It appears as though you have
something figured out here. Also since 04 thats 8 yrs. you have been doing
it that way so it seems it works or you would have changed it.
My servo amps are a commercial product, see
I just ran into a strange thing in pid.c, there is a pin
pid.1.command-deriv, which in the code is exported as a
hal INPUT pin. I don't see anywhere in the code where it
is written to, yet it appears to show the right value when observed
with Halscope.
The value IS used to compute the error
jeremy youngs wrote:
hello again, well ive eliminated the lovejoys was able to get good scalind
at .1 and .5 but not both with the same numbers, I gave up on the
microstepping and just fudged the gear ratio. However I just dont seem to
be able to get consistent scaling. Are there drives that
I have a system built from source, and updated as of 6/18.
I noticed it produces a message I have not seen before,
Cannot unhome while moving, joint 0 seemingly at random
while jogging before homing.
Can anyone tell me what the massage means?
Thanks,
Jon
Eric Keller wrote:
On Sat, Jul 7, 2012 at 10:07 PM, Jon Elson el...@pico-systems.com wrote:
Yes, I remembered there was some discussion of this, couldn't remember
quite
how far back. So, the situation is : if not homed, and moving, and you
get
an E-stop, it produces the message
Oscar Chaides wrote:
spanish docs
Linux_FAQ_es.txt
copy_and_run_es.txt
Hey, cool! I recall you said you'd be working on this, glad it is finally
coming along. My Spanish is VERY rudimentary, so I won't be able
to critique it, but this expands LinuxCNC to a large group of people
who were
Gene Heskett wrote:
FWIW, rtai-3.9 was released today, claims to support up to 2.6.38.8, and
with the bfs scheduler patch too if its compatible with rtai, that is one
sweet kernel. The interactivity between the machine and the user has to be
experienced to be believed it can be that good.
Darren Conway wrote:
Hi
Would the Raspberry Pi be a candidate for running EMC?
There is no hardware floating point. I think that would be a major killer.
Software emulation is slow, but the typical RT package probably does not
support the FP emulation for real time kernel modules.
At the
On 20 July 2012 07:38, Darren Conway darren.con...@xtra.co.nz wrote:
Would the Raspberry Pi be a candidate for running EMC?
OOps, the Pi website now shows it DOES have hardware floating point, I'd
swear a few months ago it said there was NO hardware FP. Well, that helps.
Jon
Charles Steinkuehler wrote:
My current plan is to bit-bang GPIO pins based on code from the
parallel port driver, but adding a bit of electronics would probably
make things much easier. I'll evaluate that option once I see where I
get with software stepgen.
Well, it totally depends on the
andy pugh wrote:
On 20 July 2012 17:31, Jon Elson el...@pico-systems.com wrote:
There is no hardware floating point. I think that would be a major killer.
Software emulation is slow, but the typical RT package probably does not
support the FP emulation for real time kernel modules
Karl Schmidt wrote:
On 07/20/2012 11:47 AM, Jon Elson wrote:
Charles Steinkuehler wrote:
My current plan is to bit-bang GPIO pins based on code from the parallel
port driver, but
adding a bit of electronics would probably make things much easier.
What would the bit
Karl Schmidt wrote:
In my mind, a single chip uP system, with just a small assembly program,
could do the pulse
generation busy work and make the position information available to the
PC-system with time left
over to play an audio stream. The question is if there is going to be a
Karl Schmidt wrote:
The question is if there is going to be a latency issue of bringing
that position information back into the PC without any problematic latency -
( the outer loop is
running much slower - so I doubt there is an issue. )
Shouldn't be much problem reading a register.
Jon Elson wrote:
If somebody wants to try to build a driver for the ARM on-chip
peripherals that would be very interesting.
Oh, one other problem with most of these systems is that only a VERY
small portion
of the available package pins are brought out to expansion header pins
on the board
Michael Haberler wrote:
It has happened to me several times now that I looked into some software
package and only then learn out that it is perceived to be incompatible with
the LinuxCNC license.
To cut the waste of time and effort, I've started a Wiki page on license
Chris Radek wrote:
On Sun, Jul 22, 2012 at 11:57:55AM -0500, Jon Elson wrote:
I think this is only an issue for distributions of the software. So, if
LinuxCNC wants to include a
particular package on the iso CD image, then it has to meet certain
requirements.
This is totally
ELHIMA Moustapha wrote:
Dear All
I'm thinking to put a potentiometer on my cnc lathe to control the feedrate,
for my machine
To control my machine I have just used 2 parports and I have the possibility
to use an another one, could you tell me if it's possible with HAL to hook my
1 - 100 of 1015 matches
Mail list logo
