[Emc-developers] Dev environment for gscreen
Hi, I am designing a custom gscreen skin and I need help setting up my development environment. I’m working on a raspberry Pi 4 and running 2.8.2 as set up by the pi image. I’m using Visual Studio Code. As of now, I am testing it by using the print() statement and running LinuxCNC from the command line. I hope you can help me with the following: * How do I set up the dev environment so that vscode intellisense works with all the imported libraries? * How do I attach the debugger to the custom gscreen handler.py file? * is there a general guide for how to configure the development environment for this? * is there a programming manual for gscreen? First time using Python, first time using Glade, and first time using VS Code. Thanks, Thaddeus Waldner ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] issue in gmoccapy for lathe
Hey Guys, I think I've run into a snafu with the latest update of buildbot master branch with gmoccapy 3.1.3.10. When setting a turning tool, I only have a tool touchoff X option button, nothing for Z. Anyone else run into this? even making a simulated stepconf setup yields the same result. Not sure if i'm missing something here or not. I don't recall having an issue setting Z in the past but I haven't used the machine in a while until the other day, now i'm trying to set up something and not having much luck because of the missing Z set on the tool offset page. Phil T. The Feral Engineer Check out my LinuxCNC tutorials, machine builds and other antics at www.youtube.com/c/theferalengineer ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Mon, 18 Apr 2022, andy pugh wrote:
Date: Mon, 18 Apr 2022 00:59:07 +0100
From: andy pugh
Reply-To: EMC developers
To: EMC developers
Subject: Re: [Emc-developers] curious about the ethernet protocol
On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers
wrote:
IIUC the GCODE interpreter runs in the non-realtime part. It sends the step
instructions to a card to execute the steps. This is obvious when using a
LPT port, but how does this work via Ethernet?
Snip-
As far as I know an ethernet smoothstepper does not do this. I don't
even think that they "buffer" as is often suggested. In fact I think
that they move all of the "tc" on to the hardware. So probing and
spindle-synched motion is handled inside the card, not on the host
controller.
An external card with a TC probably has multiple levels of buffers...
(back when we made some MACH 3 compatible hardware, it was in fact buffered
PVTA motion so Mach3 did the trajectory planning and the external hardware
just played out a PVTA sequence from a FIFO)
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
?? George Fitch, Atlanta Constitution Newspaper, 1912
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
You can do all sorts of fancy stuff - with realtime tucked comfortably in the computer... (not excluding torch height control all within linuxcnc) https://www.youtube.com/shorts/nViXP9SsdWc Linuxcnc is like a large real time lego set... sam On Sun, Apr 17, 2022 at 8:42 PM Rod Webster wrote: > So Andy's post brings is right back to Peters comment > > Basically just following the LinuxCNC model of having the host be the > > locus of control. This is the basic difference between buffered systems > > like Mach and LinuxCNC. By having the LinuxCNC host be the controller > > you gain a number of advantages: > > > 1. The external hardware is simpler (and more uniform) > > 2. The more complex parts of the control are located on a host > > with basically unlimited memory and CPU capabilities so real time > behaviour > > is extensible by a large group of users/developers using standard tools. > > 3. Specifically, returning actual position allows use of the following > > error mechanism for tuning and robust fault detection without a side > > channel of status information. > > > Aside from continual improvement to the core tc (trajectory controller), > The hidden gem in Linuxcnc is the ability to write your own components in C > that are compiled and installed with a single command. Once implemented in > hal (hardware extraction layer) via your hal file with loadrt and addf > commands, your custom component has access to that infinite memory and CPU > capability AND it is treated as if it is part of the Linuxcnc core viar the > controlling servo thread. > > Whether it is possible to use a serial modbus encoder in the real time > environment might be problematic though. You might be able to use external > hardware with a UART (perhaps from Mesa) that accumulated the encoder count > for linuxcnc to read every millisecond. In theory, you should only need one > UART in a multidrop environment but whether a serial protocol would be fast > enough to service all encoders in a single servo thread cycle would be a > moot point. > > If you wanted an alternative to Mesa there are always solutions from Jon or > you could use ethercat. Linuxcnc will not care at the tc level. > > Rod Webster > *1300 896 832* > +61 435 765 611 > Vehicle Modifications Network > www.vehiclemods.net.au > > > On Mon, 18 Apr 2022 at 10:00, andy pugh wrote: > > > On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers > > wrote: > > > > > IIUC the GCODE interpreter runs in the non-realtime part. It sends the > > step > > > instructions to a card to execute the steps. This is obvious when > using a > > > LPT port, but how does this work via Ethernet? > > > > There are some steps missing here that have not been explained in > > later posts which might explain the process. > > > > The interpreter, as you said, runs in user space, it reads G-code and > > converts it in to "canonical commands" which are fed to the motion > > queue. > > These commands are the basic things that a CNC machine needs to do. It > > is worth noting that many G and M-codes only affect the internal > > status of the interpreter, and that is partly why the program line > > counter skips non-movement commands, they simply don't exist in te > > queue) > > Also, the interpreter is a pluggable module, it doesn't have to be > G-code. > > > > There are several steps from here, including converting the commands > > into NML messages ( > > > > > https://www.nist.gov/publications/neutral-message-language-model-and-method-message-passing-heterogeneous-environments > > ) but eventually the commands get to the "trajectory planner" (tp) > > (userspace) where they are put into the motion queue, which is > > consumed by the (realtime) "trajectory controller" (tc). > > > > Every 1mS the tc calculates new positions for all axes, and puts those > > positions on to HAL pins. > > > > What happens next depends on the system. With an LPT system the HAL > > "stepgen" component 1mS thread reads how many steps have been made in > > the last period, and from that and the new position calculates the > > required step-rate to hit the new position at the end of the current > > period. Then, in the fast thread the (integer maths only) step > > generator makes the pulses. > > > > With a Mesa or Pico stepper system there is no fast thread, the HAL > > driver does the same calculations as the LPT driver, though, but > > passes the required step rate through PCI, EPP, SPI or ethernet to the > > FPGA (or processor) on the card by writing to registers on the card. > > > > So, the cards are doing very little. > > > > As far as I know an ethernet smoothstepper does not do this. I don't > > even think that they "buffer" as is often suggested. In fact I think > > that they move all of the "tc" on to the hardware. So probing and > > spindle-synched motion is handled inside the card, not on the host > > controller. > > > > -- > > atp > > "A motorcycle is a bicycle with a pandemonium attachment and is > >
Re: [Emc-developers] curious about the ethernet protocol
So Andy's post brings is right back to Peters comment Basically just following the LinuxCNC model of having the host be the > locus of control. This is the basic difference between buffered systems > like Mach and LinuxCNC. By having the LinuxCNC host be the controller > you gain a number of advantages: 1. The external hardware is simpler (and more uniform) > 2. The more complex parts of the control are located on a host > with basically unlimited memory and CPU capabilities so real time behaviour > is extensible by a large group of users/developers using standard tools. > 3. Specifically, returning actual position allows use of the following > error mechanism for tuning and robust fault detection without a side > channel of status information. Aside from continual improvement to the core tc (trajectory controller), The hidden gem in Linuxcnc is the ability to write your own components in C that are compiled and installed with a single command. Once implemented in hal (hardware extraction layer) via your hal file with loadrt and addf commands, your custom component has access to that infinite memory and CPU capability AND it is treated as if it is part of the Linuxcnc core viar the controlling servo thread. Whether it is possible to use a serial modbus encoder in the real time environment might be problematic though. You might be able to use external hardware with a UART (perhaps from Mesa) that accumulated the encoder count for linuxcnc to read every millisecond. In theory, you should only need one UART in a multidrop environment but whether a serial protocol would be fast enough to service all encoders in a single servo thread cycle would be a moot point. If you wanted an alternative to Mesa there are always solutions from Jon or you could use ethercat. Linuxcnc will not care at the tc level. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Mon, 18 Apr 2022 at 10:00, andy pugh wrote: > On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers > wrote: > > > IIUC the GCODE interpreter runs in the non-realtime part. It sends the > step > > instructions to a card to execute the steps. This is obvious when using a > > LPT port, but how does this work via Ethernet? > > There are some steps missing here that have not been explained in > later posts which might explain the process. > > The interpreter, as you said, runs in user space, it reads G-code and > converts it in to "canonical commands" which are fed to the motion > queue. > These commands are the basic things that a CNC machine needs to do. It > is worth noting that many G and M-codes only affect the internal > status of the interpreter, and that is partly why the program line > counter skips non-movement commands, they simply don't exist in te > queue) > Also, the interpreter is a pluggable module, it doesn't have to be G-code. > > There are several steps from here, including converting the commands > into NML messages ( > > https://www.nist.gov/publications/neutral-message-language-model-and-method-message-passing-heterogeneous-environments > ) but eventually the commands get to the "trajectory planner" (tp) > (userspace) where they are put into the motion queue, which is > consumed by the (realtime) "trajectory controller" (tc). > > Every 1mS the tc calculates new positions for all axes, and puts those > positions on to HAL pins. > > What happens next depends on the system. With an LPT system the HAL > "stepgen" component 1mS thread reads how many steps have been made in > the last period, and from that and the new position calculates the > required step-rate to hit the new position at the end of the current > period. Then, in the fast thread the (integer maths only) step > generator makes the pulses. > > With a Mesa or Pico stepper system there is no fast thread, the HAL > driver does the same calculations as the LPT driver, though, but > passes the required step rate through PCI, EPP, SPI or ethernet to the > FPGA (or processor) on the card by writing to registers on the card. > > So, the cards are doing very little. > > As far as I know an ethernet smoothstepper does not do this. I don't > even think that they "buffer" as is often suggested. In fact I think > that they move all of the "tc" on to the hardware. So probing and > spindle-synched motion is handled inside the card, not on the host > controller. > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers wrote: > IIUC the GCODE interpreter runs in the non-realtime part. It sends the step > instructions to a card to execute the steps. This is obvious when using a > LPT port, but how does this work via Ethernet? There are some steps missing here that have not been explained in later posts which might explain the process. The interpreter, as you said, runs in user space, it reads G-code and converts it in to "canonical commands" which are fed to the motion queue. These commands are the basic things that a CNC machine needs to do. It is worth noting that many G and M-codes only affect the internal status of the interpreter, and that is partly why the program line counter skips non-movement commands, they simply don't exist in te queue) Also, the interpreter is a pluggable module, it doesn't have to be G-code. There are several steps from here, including converting the commands into NML messages ( https://www.nist.gov/publications/neutral-message-language-model-and-method-message-passing-heterogeneous-environments ) but eventually the commands get to the "trajectory planner" (tp) (userspace) where they are put into the motion queue, which is consumed by the (realtime) "trajectory controller" (tc). Every 1mS the tc calculates new positions for all axes, and puts those positions on to HAL pins. What happens next depends on the system. With an LPT system the HAL "stepgen" component 1mS thread reads how many steps have been made in the last period, and from that and the new position calculates the required step-rate to hit the new position at the end of the current period. Then, in the fast thread the (integer maths only) step generator makes the pulses. With a Mesa or Pico stepper system there is no fast thread, the HAL driver does the same calculations as the LPT driver, though, but passes the required step rate through PCI, EPP, SPI or ethernet to the FPGA (or processor) on the card by writing to registers on the card. So, the cards are doing very little. As far as I know an ethernet smoothstepper does not do this. I don't even think that they "buffer" as is often suggested. In fact I think that they move all of the "tc" on to the hardware. So probing and spindle-synched motion is handled inside the card, not on the host controller. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > Unfortunately that circles back to the mesa availability problems :-( > > 5i25's are not available? I haven't checked recently. > You can almost replace the Mesa store by an out-of-stock sign ;) > Would a 7i92 also work? > > It looks like it would, its basicaly a 5i25 with a cat connector > replacing the pci interface of the 5i25 and if the H version is available > that would simplify cable making, db-25's have been problematic as the > cable can work loose in the center of the cap, losing 1 or more > connections. Urgh. Even when screwed in? I have not had similar problems with the 26 pin header style > and you can easily get both cables out to their respective bobs with only > one style of common connector. I also would prefer the H. But you guessed it - not in stock :-( Up to 5 feet, I don't worry about it. > Should be less - but good to know. I consider that just as > important, and explains why I went with a 7i90 on the pi, reflashed to an > SPI interface. Which on the pi's, writes a 32 bit serial data packet to > the 7i90 at 42 megabaud, and reads back at 25 megabaud. Apparently > without interference from the net port. That could probably be done with > a bash script, making it relatively painless. > I find SPI also quite interesting. But I am not aware of a PCI(e)-SPI card. I don't want to be tied to using the RPi. > Seems I either need to go with Remora or a Parallel BOB. > > And I would probably have to get a PCI/PCIe Parallel Port. > > I don't get any hits for cnc stuff out of a DDG search for Remora. link > url? > https://github.com/scottalford75/Remora-NVEM And the NVEM boards are at around 60-80 USD. Not a Mesa but... > > How come the 5i25 is faster? > > mobo parports are usually accessed thru the bios, which generally takes > some number of microseconds just to wade thru the bios code and do it. > The 5i25, sitting on the pci bus can update its outputs or read its > inputs in sub-microsecond time frames. > The parallel port I'd be getting would also be PCI/PCIe. So I guess that would be fine then. The old PC should arrive on Tue/Wed. Not sure what I will find. Fingers crossed :) So the advantage of a single 7I92 vs getting two PCI(e) Parallel Ports is that the Mesa holds the stepgen. Other than that it would be about the same - just connecting a simple 15 USD BOB. Right? ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sun, 17 Apr 2022, Torsten Curdt via Emc-developers wrote:
Date: Sun, 17 Apr 2022 13:47:40 +0200
From: Torsten Curdt via Emc-developers
To: EMC developers
Cc: Torsten Curdt
Subject: Re: [Emc-developers] curious about the ethernet protocol
Maybe finding an old parallel port machine might still be the easier
route
:-/
Better yet, a pci-e buss and a 5i25 card.
5I25 is PCI
6I25 is PCIE
7I92 is Ethernet
Mesa still has 6I25s and 7I92s
a 5I25, 6I25 or 7I92 are basically interchangable
Ethernet is especially good If there is a long distance between the
control PC and the drive box (larger machines)
Unfortunately that circles back to the mesa availability problems :-(
Would a 7i92 also work?
Seems I either need to go with Remora or a Parallel BOB.
And I would probably have to get a PCI/PCIe Parallel Port.
two parports lots faster than a mobo parport.
mobo = motherboard?
How come the 5i25 is faster?
cheers,
Torsten
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sunday, 17 April 2022 11:00:31 EDT Jérémie Tarot wrote: > Le dim. 17 avr. 2022 à 13:50, Torsten Curdt via Emc-developers < > > emc-developers@lists.sourceforge.net> a écrit : > > > > Maybe finding an old parallel port machine might still be the > > > > easier > > > > route > > > > > > > > :-/ > > > > > > Better yet, a pci-e buss and a 5i25 card. > > > > Unfortunately that circles back to the mesa availability problems :-( > > Would a 7i92 also work? > > 7i92+7i76 would surely do wonders! I'm using a 5i25+7i76 and a bob on two of my 4 machines, works quite well. The major diff is the cat5 interface at udp speeds. 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, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sunday, 17 April 2022 07:47:40 EDT Torsten Curdt via Emc-developers wrote: > > > Maybe finding an old parallel port machine might still be the > > > easier > > > route > > > > > > :-/ > > > > Better yet, a pci-e buss and a 5i25 card. > > Unfortunately that circles back to the mesa availability problems :-( 5i25's are not available? I haven't checked recently. > Would a 7i92 also work? It looks like it would, its basicaly a 5i25 with a cat connector replacing the pci interface of the 5i25 and if the H version is available that would simplify cable making, db-25's have been problematic as the cable can work loose in the center of the cap, losing 1 or more connections. I have not had similar problems with the 26 pin header style and you can easily get both cables out to their respective bobs with only one style of common connector. That reduces you to only one db25 per cable unless you can find a bob that takes the 26 pin header. Those bob's are rare indeed. Because of the lack of termination resistors on a typical parport bob, if the cables are more than 5 feet, the data integrity would be improved by src terminating at the 7i92 by adding a nominally 120 ohm resistor in series as the ribbon cables impedance is nominally 120 to 130 ohms. The resistor absorbs a large part of the echo from the unterminated bob. Up to 5 feet, I don't worry about it. Note: I'm talking terminations not in the sense of screw terminal's but in terms of a transmission line's characteristic immpedance. VSWR IOW. However, unless your mobo has two ethernet ports, you'll have to disconnect the 7i92, plug in a cat6 to your switch/router and reconfigure the network to get online and update the pc. I consider that just as important, and explains why I went with a 7i90 on the pi, reflashed to an SPI interface. Which on the pi's, writes a 32 bit serial data packet to the 7i90 at 42 megabaud, and reads back at 25 megabaud. Apparently without interference from the net port. That could probably be done with a bash script, making it relatively painless. The huge disadvantage to that is that the 7i90 is those 50 pin scsi connectors are connected directly to the fpga, and needs 3 of the 7i42TA's to serve as fpga destroying noise absorbers, and gives you its 72 i/o's on the usual green termination facilities, while raising the cost to around $200 for all 4 pieces. The ease of wiring it up pays for the 7i42TA's IMO. At the time I built it, that was all that was available if you wanted a pi to talk to your machinery. That 7i90HD card can also be driven from a parport, and comes that way so must be reprogrammed with mesaflash to use the SPI. > Seems I either need to go with Remora or a Parallel BOB. > And I would probably have to get a PCI/PCIe Parallel Port. I don't get any hits for cnc stuff out of a DDG search for Remora. link url? > two parports lots faster than a mobo parport. > > > mobo = motherboard? Yup. > How come the 5i25 is faster? mobo parports are usually accessed thru the bios, which generally takes some number of microseconds just to wade thru the bios code and do it. The 5i25, sitting on the pci bus can update its outputs or read its inputs in sub-microsecond time frames. > cheers, > Torsten Take care and stay well. 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, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
Le dim. 17 avr. 2022 à 13:50, Torsten Curdt via Emc-developers < emc-developers@lists.sourceforge.net> a écrit : > > > Maybe finding an old parallel port machine might still be the easier > > > route > > > :-/ > > > > Better yet, a pci-e buss and a 5i25 card. > > > Unfortunately that circles back to the mesa availability problems :-( > Would a 7i92 also work? > 7i92+7i76 would surely do wonders! ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> > Maybe finding an old parallel port machine might still be the easier > > route > > :-/ > > Better yet, a pci-e buss and a 5i25 card. Unfortunately that circles back to the mesa availability problems :-( Would a 7i92 also work? Seems I either need to go with Remora or a Parallel BOB. And I would probably have to get a PCI/PCIe Parallel Port. two parports lots faster than a mobo parport. > mobo = motherboard? How come the 5i25 is faster? cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] suggestions to improve HOMECOMP/HOMEMOD custom homing infrastructure
I'm about 1800 or so lines into a custom HOMECOMP.comp homing module but there are two things I have observed that might be useful enhancements that fall outside of HOMECOMP.comp 1. Could the normal component period variable be implemented in a HOMECOMP? Currently its not supported. The fperiod macro exists (and errors). I've had to implement my own low level timing solution in the absence of period. 2. Could a new INI file homing flag be added to homing.h? Lets call it HOMING_CUSTOM_MOD or similar that could be used hand in hand with a custom homing module? It has occurred to me that a custom homing module could support Linuxcnc's existing homing infrastructure AND a custom solution if such a flag existed. That way the custom homing module could be restricted to joints where this flag was set. I will say, writing a HOMEMOD is not for the faint hearted. I still have a fair bit to do before I can even think about actually homing! Anyway, I'd like to pass on thanks to Dewey for coming up with this enhancement. The ability to read, write and modify custom pins is very powerful. Rod Webster *1300 896 832* +61 435 765 611 VMN® www.vmn.com.au ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
On Sunday, 17 April 2022 05:57:07 EDT Torsten Curdt via Emc-developers wrote: > > BUT my ballscrews are 05mm and planned for servo speeds. > > > > > I don't really want to go from the idea of the dynamic servo driven > > > machine to the stepper turtle :) > > > > All my stuff is steppers, but I wouldn't call a g0 move at 250 ipm a > > turtle. The whole steel framed table its on shakes. > > /me converts - that's 6.35 meter per minute - that's about 10.5cm per > second. > > I would suspect the dynamic movement (acc/dec) of a servo might > actually shake it less. Thats with accell/decel controls, steppers do that too, in LinuxCNC. > It seems like 500 ipm should be easily doable with a servo. But that's > still just reading/watching knowledge here. > > > Mach3's bob's can be used but my being a "CET" means they're not OOTB > > > CET means central european time to me - what does it mean to you? :) Certified Electronics Technician. Registered in Nebraska in 1972 as NEB-118, but the 118 was the count in the whole country. > > For folks who aren't comfy with a hot air rework soldering iron > > > surgically implanted in a right hand, that need does remove those $20 > > boards from consideration. Mesa and cnc4pc both make better bobs, but > > bring more money. > > Not an EE - but I had my first soldering iron when I was 7y :) Good, I think I was 9 yo. > > But,if you are going to use it to drive a spindle, which is "CCS" > > service. be sure and tell Jon when you order it. he'll change the > > toroid filters from ICAS to CCS, the ICAS version gets hot, the CCS > > versions doesn't. > > Why would they not be CCS? Servo's at rest don't use a lot of power. > > > Which made me curious and I started digging - down the rabbit hole > > > ;) > > > > Locally, that hole is more likely a gopher or ground hog hole. ;) > > Got more gophers than rabbits? :) Locally yes. > > > Hope that explains the status quo. > > > > Somewhat, but the ball screws at 5mm pitch is pretty much stock in > > what's commonly available. > > People usually build this CNC with 10mm pitch ball screws and open loop > 2.5Nm steppers with a parallel BOB. > I could go 2Nm or 3Nm closed loop steppers - but are still not much > wiser in terms of the boards. > > Maybe finding an old parallel port machine might still be the easier > route > :-/ Better yet, a pci-e buss and a 5i25 card. two parports lots faster than a mobo parport. > Happy Easter! > > cheers, > Torsten Back at you. > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > . 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, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] curious about the ethernet protocol
> BUT my ballscrews are 05mm and planned for servo speeds. > > > > I don't really want to go from the idea of the dynamic servo driven > > machine to the stepper turtle :) > > All my stuff is steppers, but I wouldn't call a g0 move at 250 ipm a > turtle. The whole steel framed table its on shakes. > /me converts - that's 6.35 meter per minute - that's about 10.5cm per second. I would suspect the dynamic movement (acc/dec) of a servo might actually shake it less. It seems like 500 ipm should be easily doable with a servo. But that's still just reading/watching knowledge here. Mach3's bob's can be used but my being a "CET" means they're not OOTB CET means central european time to me - what does it mean to you? :) For folks who aren't comfy with a hot air rework soldering iron > surgically implanted in a right hand, that need does remove those $20 > boards from consideration. Mesa and cnc4pc both make better bobs, but > bring more money. > Not an EE - but I had my first soldering iron when I was 7y :) > But,if you are going to use it to drive a spindle, which is "CCS" > service. be sure and tell Jon when you order it. he'll change the toroid > filters from ICAS to CCS, the ICAS version gets hot, the CCS versions > doesn't. Why would they not be CCS? > > Which made me curious and I started digging - down the rabbit hole ;) > > Locally, that hole is more likely a gopher or ground hog hole. ;) > Got more gophers than rabbits? :) > > Hope that explains the status quo. > > Somewhat, but the ball screws at 5mm pitch is pretty much stock in what's > commonly available. People usually build this CNC with 10mm pitch ball screws and open loop 2.5Nm steppers with a parallel BOB. I could go 2Nm or 3Nm closed loop steppers - but are still not much wiser in terms of the boards. Maybe finding an old parallel port machine might still be the easier route :-/ Happy Easter! cheers, Torsten ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
