Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at Tormach headquarters
Does anyone have agenda items for the meeting? I will be glad to present my servo tuning demo, but that is all I have. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] April 2023 LinuxCNC meeting at Tormach headquarters
Does anyone have agenda items for the meeting? I will be glad to present my servo tuning demo, but that is all I have. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at Tormach headquarters
Will people who plan to attend (weekend of April 22-23) please confirm? We only have a couple names so far, and Tormach doesn't want to commit their resources for a tiny crowd. Please reply here or directly to me if you plant to attend. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] April 2023 LinuxCNC meeting at Tormach headquarters
Will people who plan to attend (weekend of April 22-23) please confirm? We only have a couple names so far, and Tormach doesn't want to commit their resources for a tine crowd. Please reply here or directly to me if you plant to attend. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at Tormach headquarters
Would anyone who plans to attend please let me know, so I can get a total of attendees and inform Tormach how big the horde is going to be? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] [Emc-users] April 2023 LinuxCNC meeting at Tormach headquarters
On 3/7/23 11:10, Jon Elson wrote: On 1/18/23 18:29, Jon Elson wrote: Daniel Rogge of Tormach has mentioned that he is trying to set up a meeting in April with Robert Ellenberg, John Morris and Alex Rossler over a weekend. Does anybody have a specific date they would prefer or can't attend? We could possibly set up a meeting that partly overlaps the one with the above people. I FINALLY have a DATE! Tormach is having a meeting with the above mentioned developers from April 24 - 28. Daniel suggests we could have a LinuxCNC meeting from April 22-23 (over the weekend) and then maybe stay just a bit to meet with those others. Sorry it took so long to find out what the dates were. Would anyone who plans to attend please let me know, so I can get a total of attendees and inform Tormach how big the horde is going to be? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] April 2023 LinuxCNC meeting at Tormach headquarters
On 1/18/23 18:29, Jon Elson wrote: Daniel Rogge of Tormach has mentioned that he is trying to set up a meeting in April with Robert Ellenberg, John Morris and Alex Rossler over a weekend. Does anybody have a specific date they would prefer or can't attend? We could possibly set up a meeting that partly overlaps the one with the above people. I FINALLY have a DATE! Tormach is having a meeting with the above mentioned developers from April 24 - 28. Daniel suggests we could have a meeting from April 22-23 (over the weekend) and then maybe stay a day or 2 longer to hobnob with those other developers. Sorry it took so long to find out what the dates were. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Fwd: spindle speed output not working?
Forwarded Message Subject: Re: [Emc-developers] spindle speed output not working? Date: Mon, 6 Mar 2023 12:26:00 -0600 From: Jon Elson To: Sebastian Kuzminsky On 3/5/23 20:28, Sebastian Kuzminsky wrote: I can imagine halcmd emitting a warning if you call loadrt with an argument that's just "=", but that feels a bit over-specific for this particular user's syntax error. Well, I wonder if this behavior is documented somewhere in the docs? Since it is generic Linux command line syntax, not too many people would even know where to look, but it ought to be remarked somewhere, maybe in the hal guide. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] spindle speed output not working?
On 1/15/23 11:50, Jon Elson wrote: Hello, all, I have a user who can't get spindle speed to work. He says he is using 2.7.0 and my USC/UPC boards with the 8-bit spindle DAC board. The user sent his computer to me, and I have discovered what looks like it could be considered a bug. He had a parameter in the loadrt line like this: loadrt hal_ppmc extradac = 0x00 this caused a parameter extradac not found error from hal. The correct syntax that works is : loadrt hal_ppmc extradac=0x00 (note - no spaces between extradac and the 0x00). Is this a known issue in loadrt parameters, and would it be easy to fix? I am not sure this behavior can be tested without Pico Systems hardware, but it seems to be something intrinsic to the hal command interpreter, so it is likely to affect most loadrt commands. Anybody else run into this one? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Reminder: It's Today! (January 2023 Online Meeting)
Daniel Rogge of Tormach has mentioned that he is trying to set up a meeting in April with Robert Ellenberg, John Morris and Alex Rossler over a weekend. Does anybody have a specific date they would prefer or can't attend? We could possibly set up a meeting that partly overlaps the one with the above people. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] spindle speed output not working?
Hello, all, I have a user who can't get spindle speed to work. He says he is using 2.7.0 and my USC/UPC boards with the 8-bit spindle DAC board. When he tells it to start the spindle (I presume with M03 S1000 or similar) he gets zero out of motion.spindle-speed-out. Can anybody say what things need to be in order for the S word to be sent out from motion.spindle-speed-out? I think he is using show hal config to see the state of the hal pins. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] feed hold ?
On 12/4/22 12:16, Chris Morley wrote: The jog inhibiting code from motion-inhibit was purposely removed some time ago. Why, I don't know because it was put in by me specifically for that purpose a long while back. as for feed-hold, my guess would be the code change affected it too - probably by accident. maybe adding separate jog-inhibit pins would satisfy everyone? Yikes! I can see arguments both ways, but feed hold or feed inhibit seems like it should stop all motion, even from manual command. I guess you could have a situation where a clamp or whatever obscures the IR link, and if these inhibits prevented manually moving the axes then you are kind of stuck. In my case, I can just turn the probe controller off and clear the hold/inhibit. Yes, a separate jog-inhibit pin would be one way to make everybody happy. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] feed hold ?
On 12/4/22 10:44, Jon Elson wrote: I was demoing my touch probe yesterday and saw something odd. This probe uses IR signals, and so the interface will detect loss of IR communication and cause a feed hold. I was astonished to see that the keyboard jog keys allowed me to move the axes while feed hold was true! The probe interface sends that status to motion.feed-hold, and I have a tally LED in PyVCP to show the status. I'm using LinuxCNC 2.8.2 Looking at the docs, there is an option that needs to be set, so I tried connecting the feed hold to motion.feed-inhibit. That made no difference it still allowed jog keys to move the axes when motion.feed-inhibit was true! This seems like a real bug! Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] feed hold ?
I was demoing my touch probe yesterday and saw something odd. This probe uses IR signals, and so the interface will detect loss of IR communication and cause a feed hold. I was astonished to see that the keyboard jog keys allowed me to move the axes while feed hold was true! The probe interface sends that status to motion.feed-hold, and I have a tally LED in PyVCP to show the status. I'm using LinuxCNC 2.8.2 Can anyone duplicate this? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] A vision for working now to LinuxCnc version 10
On 12/3/22 18:57, chris morley wrote: I am not sure why you are hostile. I am really trying to understand exactly what you want. Machinekit did work on networking, though I think it was just HAL. It's why I mentioned it. Underneath HAL there is NML that links major sections of LinuxCNC together and makes the state of major components available. NML exports the ENTIRE state of everything to all clients. This is doable on a single computer system, but causes issues on multiple networked nodes. Machinekit was trying to replace ALL NML with ZeroMQ, which was designed to do this in a networked way. Clients tell it what structures they want to subscribe to, and ONLY those structures are transmitted to that client. My understanding is that this replacement was never finished. Machinekit was aimed at work cell/robot systems and multiple instances of LinuxCNC working together in shared 3D spaces. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] manual tool change
On 11/21/22 19:35, Jon Elson wrote: I have a user who tried to implement the manual tool change button in LinuxCNC 2.8, he says there is no continue button displayed. His original code was : loadusr-W hal_manualtoolchange net tool-change iocontrol.0.tool-change => hal_manualtoolchange.change net tool-changed iocontrol.0.tool-changed <= hal_manuatoolchange.changed net tool-number iocontrol.0.tool-prep-number => hal_manualtoolchange.number net tool-prepare-loopback iocontrol.0.tool-prepare => iocontrol.0.toolprepared net tool-changed-btn hal_manualtoolchange.change_button <= parport.0.pin-15-in This would not start, as there was no parport in his system. I told him to just delete the last line, I assumed this would just use the on-screen button to continue from the tool change. But, now he doesn't get a "continue" button on the screen. Does the new version require a hardware button, or require a signal to be netted to the hal_manualtoolchange.change_button? Thanks for any insight, I don't use this feature at the moment. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] time delay hal component for lube pump
On 11/21/22 17:13, Feral Engineer wrote: Classicladder is awesome for this But, way overkill for just one function. Maybe I should use timedelay as a template and write my own one-shot component. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] time delay hal component for lube pump
Hello, all, I need a hal component for a lube pump. What I am looking for is more like a one-shot than the existing timedelay component. timedelay seems to be able to delay the start or the end of a signal, but output will follow the input after the delays occur. I wanted a component that would trigger for a set time after a trigger (or LinuxCNC starting) and then, I could or it with the spindle enables. This would ensure the lube pump starts immediately when LCNC starts, and then run whenever the spindle is on. Anybody know a better way to do this? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
On 10/24/22 15:28, Alec Ari via Emc-developers wrote: Jon, You can actually grab the sid 6.0 kernel and drop it on Bullseye and perhaps even Buster: Yes, I actually did this on a Bullseye install. I also had to install the firmware files that didn't come in along with the new kernel for some reason. Now, the graphics all works! Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] RTAI support for kernel 5.4 works so far, pending musl/math test
On 10/22/22 21:54, Alec Ari via Emc-developers wrote: I will post Debian packages for the 5.4 RTAI kernel once it's ready, but it may be a few weeks of testing. I need to fool proof Kconfig as well. I'll be using the latest Debian Bullseye 5.10 kernel config as the baseline, and just let Kconfig handle the differences once mine are plugged in. Latest config file is config-5.10.0-19-amd64. I went through a week of hell trying to get graphics working on a newer system with Intel UHD 630 graphics. It required updating to the 6.0.0 kernel and new firmware files. Of course, i really had no idea what I was doing, so I may have done it all wrong. Some online resources said at least the 5.13 kernel was required for this chipset. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] pyvcp buttons to move to arbitrary coordinates
Hello, I have a one-axis positioner set up using Machinekit and Axis, with some PyVCP buttons that go to specific pre-programmed coordinates. it would be nice to be able to type a coordinate into a dialog box and then go to that coordinate. Is there a way to do this? I can probably figure out how to add a dialog box to the PyVCP, but how does that get inserted into an MDI command like : G01 X1.234 F100 , where the 1.234 is the value typed into the dialog box? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] PCIe EPP parport issues
On 7/16/22 22:05, Jon Elson wrote: Well, the saga continues! I thought I had this all working, but then rebooted today, and could not get the MCS9900 card to work properly. I could run my diag and see the boards respond, but then when I ran some tests, the parport would lock up, and lspci -vv would show "disabled" next to the port addresses. The only way to clear it was a reboot. Same thing happened with a Siig OXPCIe952 card. It is pretty clear that either the driver or some other kernel module is taking control of the parport when I want to run at the "bare metal" level. This appears to be new behavior with this kernel on the 2.8.2 distro. So, I gave up on PCIe cards, and swapped the hard drive into a Dell 980 with a parport on the motherboard. All seems to work very well on that system. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] BIG Quirk in Axis??
I have been setting up an R2E3 mill using the 2.8.2 distribution from a couple weeks ago. I now have 2 servo amps running and tuned. Now I tried to run a stripped-down axis.ngc program, but get no motion! Then, I tried doing some moves in MDI mode, and again no motion! I can jog around just fine, but any moves in auto mode don't happen. Has anybody seen this or have any idea what is going on? I'm totally mystified! Thanks in advance for any hints. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] sudo make setuid -> cannot gain I/O privileges
On 7/27/22 10:25, Thomas J Powderly wrote: congrats on the fix Jon tomp Well, the problem is that the /usr/share/misc/pci.ids file in the LinuxCNC 2.8.2 distro has missing info. It would be good to get this fixed and re-issue the distro. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] sudo make setuid -> cannot gain I/O privileges
On 7/27/22 00:13, Alec Ari via Emc-developers wrote: I have solved one issue with the LinuxCNC 2.8.2 distribution, relating to at least the NetMos MCS9900 chip. Here are the details: The file /usr/share/misc/pci.ids has no entry for the vendor:product IDs 9710:9900. This apparently causes the driver to use some default config info that is wrong for this chip. I found this on the net, and did the following: sudo update-pciids this asked me to install wget, and then it did the update, and there now WAS an entry for 9710:9900 in /usr/share/misc/pci.ids Now lspci -vv shows : 02:00.0 Parallel controller: MosChip Semiconductor Technology Ltd. MCS9900 Multi-I/O Controller (prog-if 03 [IEEE1284]) Subsystem: Asix Electronics Corporation (Wrong ID) MCS9900 Multi-I/O Controller and after putting in the MCS9900 card, I could get my diagnostic to work! Hmm, I had been using a wrong parameter in the loadrt line, and that was causing the hal_ppmc driver to not work with some boards. So, now, both the diag and LinuxCNC work with the MCS9900, despite the Wrong ID message above. Wow, what a mess! But, once the solution is discovered, the fix is pretty easy! Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Fwd: sudo make setuid -> cannot gain I/O privileges
Forwarded Message Subject: Re: [Emc-developers] sudo make setuid -> cannot gain I/O privileges Date: Mon, 25 Jul 2022 12:18:39 -0500 From: Jon Elson To: andy pugh On 7/25/22 04:16, andy pugh wrote: On Mon, 25 Jul 2022 at 05:37, Alec Ari via Emc-developers wrote: Having CONFIG_X86_IOPL_IOPERM disabled was the problem, took me a bit to figure it out. Is that the case in the officially distributed preempt kernels? If so, then we might have a problem looming. Yes, I downloaded the 2.8.2 iso last week, and had a bunch of parport issues. These may not be related to that, I'm still trying to figure out why MOSCHIP MCS990x cards don't work at all with that download. I get this from sudo lspci -vv: 02:00.0 Parallel controller: MosChip Semiconductor Technology Ltd. MCS9900 Multi-I/O Controller (prog-if 03 [IEEE1284]) Subsystem: Device a000:2000 I believe the card is supposed to report vendor ID 9710 product ID 9900, so it may be that the serial PROM that holds the PCI enumeration data may be loaded with different/wrong values. This a000:2000 lists as Asix Electronics Corporation (Wrong ID) on devicehunt. So, I don't know what all that means, but it sure looks like somebody did something wrong. I think all the MOSCHIP cards I have now give this result. I'm accumulating a bunch of computer boxes and parport cards testing all this. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] PCIe EPP parport issues
I have been selling Syba SD-PEX10005 PCIe parallel port cards for several years, they seem to work well with most computers and LinuxCNC and my line of motion interfaces. Now, I have 2 Dell Optiplex 7010 computers that they do NOT work on. It seems that both my diagnostic program and the hal_ppmc driver don't talk to it correctly. These cards use the MOSCHIP MCS9900 or MCS9901 chip. I have one remaining Siig card that uses the Oxford Semi chip and it works. I thought I had this EPP weirdness pretty much solved, but now I'm up the creek without a paddle again. Does anybody know anything about these PCIe-EPP issues? Thanks in advance for any help! Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Quirk in Axis
I had a weird thing happen for the second time on my mill using LinuxCNC 2.8 and Axis. I was having issues with my keyboard due to a bad DIN-5 to PS/2 adapter, causing the keyboard/BIOS to lose a lot of key-up events. I was doing some semi-manual machining, going back and forth between MDI, jog (arrow) keys and the jog pendant. The lost key-up events were causing the machine to keep moving when I released the arrow keys, which alerted me to the problem. But, then. LinuxCNC got into a funny mode where the jog keys ran at maximum axis speed. Changing the feed override, jog speed or max axis speed had no effect! The only way to get back to proper jog speed was to restart LinuxCNC. Does Axis have a jog key modifier, where if you hold shift or something, it jogs faster? I did not think to try clicking shift to see if it would reset this state. Anyway, I have fixed that bad adapter and all is back to normal, but it was a few moments of "What the Hell is it doing?". Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] PCIe parallel port cards
Hello, all, I sell PCIe parallel port cards to go with my line of parallel port-connected motion interface boards. I have found some boards that I can't make work. My default is the Syba SD-PEX10005 which uses either the MCS9900 or 9901 chip. I recently bought what were supposed to be the same model, but they were some other brand with a similar model # : SI-PEX10010. I couldn't figure out how to get them to work with my boards. These have the WCH CH382L chip, vendor ID 1C00, product ID 3050. Has anybody run into these and figured out how to make them work in EPP mode? Thanks, Jon ___ 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 4/20/22 13:26, Torsten Curdt via Emc-developers wrote: But to me the whole idea breaks down when using a Closed Loop Stepper or a Servo. At least unless you feed the encoders into LinuxCNC it seems to heavily weaken the idea. Yes, that's the whole idea! The encoder is read by LinuxCNC, PID processes the difference between commanded and actual position, and sends out commands to the motor drive to minimize error. LinuxCNC originally came from the servo world, and various stepper "back ends" were later applied. You make it sound so common :) Are there boards where you can just connect the 4 encoder pins and turn that into two signals to read by LinuxCNC? (as Gene suggested) Yes, Pico Systems, Mesa, and a few others. And let's say the closed loop driver tries to fix the difference between commanded and actual position - you would still also feed the encoders through to LinuxCNC? Couldn't the two loops cause problems? If you use a velocity servo drive, then MOST of the gain is in the drive, and the PID loop is just keeping small errors from creeping in. I (Pico Systems) make 3 different systems for use with LinuxCNC. First came the PPMC, which was an expandable system to control analog velocity servos. Then, I came up with a stepper controller, which had encoder counters and step generators. On that, the encoder counters could be selected to count the steps produced, so it could run open-loop. Then, I hacked up that unit to generate PWM instead of steps (constant pulse rate, varying pulse width) to control servo motors. Jon ___ 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 4/20/22 11:53, Torsten Curdt via Emc-developers wrote: But to me the whole idea breaks down when using a Closed Loop Stepper or a Servo. At least unless you feed the encoders into LinuxCNC it seems to heavily weaken the idea. Yes, that's the whole idea! The encoder is read by LinuxCNC, PID processes the difference between commanded and actual position, and sends out commands to the motor drive to minimize error. LinuxCNC originally came from the servo world, and various stepper "back ends" were later applied. Jon ___ 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 4/16/22 12:17, Torsten Curdt via Emc-developers wrote: But this feedback loop decouples the real position from the meant-to-be position. (expressed in the following error) And I don't see how the real position could be reported back to LinuxCNC so it's still in full control of the movement. ...unless you connect the encoder directly to the Mesa instead of the Closed Loop Stepper driver. You can send the encoder feedback to lcnc as well as the drive using splitter. Ah, interesting. The encoders on closed loop steppers seem to usually have 4 pins. (EA+,EB+,EB-,EA-) Does that mean it requires 4 inputs per motor? Or would this somehow be normalized into STEPs and DIRs? Or what does LinuxCNC expect? The +/- indicate a differential pair, for noise rejection. The conversion to a single signal would be done in a comparator IC at the input. The splitting would not work for the servos that have the driver integrated though. For example JMC Servos can only provide feedback via modbus for example. So I guess they wouldn't be really ideal to work with unless LinuxCNC could also poll the modbus as a feedback channel. It sounds like the ideal LinuxCNC setup would be a very dump driver (without encoder support) and a stepper/servo with just an exposed encoder. And then have LinuxCNC take care of everything. But, then, you would be running blind, with no actual position available at the computer. This will work, of course, and is simpler, but you are trusting the servo drives to ALWAYS have the machine at the commanded position. The advantage of closing the loop in the computer is that you can always graph the following error to determine if the machine is accurately following the G-code program. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] latency issues on i7 CPU
I have a customer that has installed 2.8.2 from the iso onto a system with the Intel i7 CPU. He is getting rotten latency jitter, around 66 us. He intends to use it with my Unversal Stepper Controller, which needs better jitter than that. He has not made any changes to the stock install. I looked in the RT performance database, but didn't find much i7 info in there.\ Does anyone have suggestions on what to adjust? Isolcpus, SMI, vesa drivers, whatever? Thanks for any hints, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Mitsubishi meldas MDS-B-SVJ2-10 compatibilty
On 7/12/21 10:59 PM, Jon Elson wrote: Hello, all, I have a customer that has a router with Meldas MDS-B-SVJ2-10 brushless servo drives. I tried digging through the manuals. It looks like the drives are daisy-chained through some protocol from a Mitsubishi proprietary controller. There is no mention of the protocol. Does anybody know if these drives can be controlled with any of the standard schemes - analog velocity command, step/dir, etc? ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] GWiz Wizard
On 06/04/2021 05:35 PM, John Thornton wrote: I noticed that the GWiz Wizard has not been touched for 12 years and seems to be unfinished. Should we depreciate that from master and remove it from the documents? I was interesting in this as an extension to LinuxCNC. I converted one of my personal "wizards" to python a long time ago to see how difficult it was. Recently, I published source code for ALL my wizards on my web site. These are all in c, and generate g-code compatible with LinuxCNC. (See http://pico-systems.com/gcode.html for the links.) If somebody wanted to convert these to GWiz, or straight Python, please be my guest. I use these programs very often to generate my G-code for machining panels. Probably, others have similar programs that could collectively make up a pretty good set of wizards. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] flipflop
On 05/29/2021 09:56 AM, Jeff Epler wrote: On Tue, Apr 06, 2021 at 09:05:51PM +0100, andy pugh wrote: I wonder why the output pin of flipflop.comp is of type io? Perhaps it was intended for a specific purpose? flipflop only drives a value onto its output when it is clocked or when its set input is true. The theory was probably that there was some way to make other state-holding elements out of this, such as an SR-latch. I have no idea whether this is used. Having it as I/O might make it easy to set the initial state with a setp, without requiring any additional HAL components or nets. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] chart of arrays
On 05/01/2021 06:24 AM, andy pugh wrote: On Sat, 1 May 2021 at 03:53, Jon Elson wrote: Most of the work in Machinekit was to install Robert Ellenberg's trajectory planner and then remove as much NML as possible to make parts of LinuxCNC work across the net. The big problem with NML is it uses a shared memory region I don't think that NML is meant to be limited to that, in fact as far as I know it was specifically intended for distributed, cross-platform, communication. https://www.nist.gov/el/intelligent-systems-division-73500/networked-control-systems-group/nml-programmers-guide-c Yes, and at one time (EMC1), this actually worked pretty well. But, since EMC2/LinuxCNC with hal, the shared memory structure has grown like topsy, and it no longer makes sense to send the WHOLE THING every ms to all nodes in the distributed system. Pretty much, NO part of the distributed system needs ALL of the shared memory area, that's one of the big issues the Machinekit developers were trying to address. None of this really affects 90+ % of the LinuxCNC users, I think Michael Haberler was trying to find something really far out to apply his talents to. Certainly, there are some fairly far out applications such as multiple robots coordinating to manipulate the same object, or in the same space. This might be extending Machinekit into a zone even the major machine tool builders are rarely getting involved in. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] chart of arrays
On 04/30/2021 08:16 PM, Gene Heskett wrote: And unless you intend to support a platform that while it might be capable of it, has virtually no common i/o hardware with any other platform. Machinekit is not bound to the ARM architecture in any way, It happens to be easily installed on the Beagle Bone, but it will run fine on PCs. Most of the work in Machinekit was to install Robert Ellenberg's trajectory planner and then remove as much NML as possible to make parts of LinuxCNC work across the net. The big problem with NML is it uses a shared memory region, which works GREAT on a single CPU or multi-core CPU, but causes a lot of overhead when crossing the network. NML treats the entire shared memory as a single object. zero mq allows requestors to tell it what structures they need, and then only that part is sent to that node. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] chart of arrays
On 04/30/2021 01:47 PM, Alan Condit wrote: I think that one of the ways to re-ignite LinuxCNC is to pull some of the changes that were done in Machinekit back into LinuxCNC. However, some (maybe all) of those changes were done with no thought to release versioning. That being said, those changes were important to some of the former active development members. I don’t know if we could look at the changes and possibly merge them into a “3.0” release. I believe some of the things that were done there were to enable parts of LinuxCNC to run on different nodes over the net. This required all communication to be done through zero mq. Zero mq looks to be quite neat for this, but I gather the work involved was VERY substantial, and apparently, it was never finished. The desire was to enable work cells where multiple machines and robots would be working in the same volume without interference. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] chart of arrays
On 04/29/2021 07:06 AM, Stuart Stevenson wrote: I can hardly wait until AI (the real magic) lets us speak in our native tongue and have AI generate error free code in real time. It should be very soon now. "Very soon", in the geological scale of time? Yes, sure. In our lifetimes (in the scale of the older members of this group? I have my doubts. IBM demoed a "talking typewriter" to TV media in the late 1950's, I think. It was a colossal embarrassment. It apparently worked fairly well on the speakers they tested it with. Walter Cronkhite's voice was different enough that it bombed terribly. I think we are finally REALLY close with speech to text, only 60+ years later. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] chart of arrays
On 04/28/2021 06:08 AM, Matt Shaver wrote: I think what Stuart wants is a diagram of the data structures in Linuxcnc that visually represents their scope and that shows what code accesses them. Yes, that would be lovely, but would likely be the size of a street map of Seoul, S. Korea! LinuxCNC is a large program, with lots of data being accessed by many functions. I think, maybe, the only way to actually do this is to have a program that goes through the entire source, extracting all structures and access to them, and put it all in a database. Then, you could have a program that finds all the structures that match an expression, and tells what functions access that structure. Bonus points for showing which functions write to the structure. This would be a great tool, maybe somebody has written such a tool. If not, I'll bet it would be found useful by a bunch of others. To do it right, the scanning part of the program might look a lot like a C compiler. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] using ats 667's to generate z pulses.
On 04/16/2021 12:30 PM, Gene Heskett wrote: Greetings all; I am still looking for a little help in rigid tapping. OK, some other thoughts. You should use Halscope to get a trace of following error when doing the rigid tapping move, and see if there are any spikes in the error right around the reversal. One other thing, historically, the trajectory planner ran at 1/10th the rate of the servo thread. This is set in the .ini file. You should make sure the traj. planner is running at the full servo thread rate. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] using ats 667's to generate z pulses.
On 04/17/2021 04:50 AM, Gene Heskett wrote: Depends on which gear Jon. I have switches on the knob, and I switch encoder scales in some hal stuff according to the switches. The effective scales are something over 7000/1 in high gear, and a similar fudge factor over 14,000 in low gear. This was determined by recording the encoder count at turn 3, stopping the count at turn 103, and subbing the first count from the second and dividing by 100, in each gear. But thats never changed as I always tap in low gear. And I've got taps up to 7/16" in my tap hats. OH, you have the encoder on the other side of a gearbox from the spindle? The backlash in the gears is probably 25X worse that the error from direction change, unless that encoder situation is accumulating. Or, of course, you could have some kind of a noise issue. On a quick reverse, I hear the iron in the motor chirp from that limiter, but the reversal is contoured by a limit3 in front of your pwm-servo, in both directions, to stop z following errors at reversals. I could reverse faster, but z can't keep up. In low gear, the spindle motor inertia is the big lag, so turnaround times are about 400 milliseconds running wide open in either gear. At tapping speeds, 500 or less, 100 milliseconds and no chirp. Since I don't seem to have a problem with torque, I tap with the belts in the highest-speed setting, and let the motor run slow, at about 20 Hz or so from the VFD. I do use Alum-Tap, which is a truly magic tapping fluid. You can EASILY feel the reduced torque when hand tapping aluminum, maybe half the torque as when using cutting oil. Not stocked locally. Wish it was. I have no idea if the company is even still in business. But, I imagine there are other aluminum tapping fluids that are just as good. One other issue, could there be backlash in your Z drive? I have less than .0015" backlash in my Z drive. Last time I checked last fall mine wasn't up to 2 thou yet. This could also be related to the post itself being out of square which has the obvious effect of pushing the tap sideways as it descends into the hole. I need to buy a circular square, grab the post with the hoist I use to move that bs-1 around, and pull its bolts and ream the holes one size bigger so I can adjust it plumb like it should be. Cheap chinese mill. Thats been on my todo list for 3 or 4 years since I discovered it wasn't square. It might even need a reynolds wrap shim to plumb it for and aft too. Won't know till I get the square, or make one on the sheldon. But I don't have stock that big. Yes, that should be adjusted, for sure. My method of tramming was to write a program to mill a circular path in a piece of scrap with a small end mill. Step down in Z a few thousandths at a time until it mills all the way around. Then, move to the center and mount a dial test indicator in the spindle. You then sweep the circle and look for high and low spots at 0, 90 180 and 270 degrees. I have to worry about wear on the ways, so it actually gives a saddle-shape. But, after adjusting the head, I can get it well under .001" deviation at the opposite points. That's as good as you can get it with wear on the ways. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] using ats 667's to generate z pulses.
On 04/16/2021 12:30 PM, Gene Heskett wrote: Greetings all; I am still looking for a little help in rigid tapping. Since the GO704 can only muster around 2 hp in its current drive configuration, its often that I have to write a peck routine where each peck goes just a fraction of a turn farther until the tap is deep enough. But something is displacing it vertically just enough to make noticeably sloppy fitting threads. Yes, I can see how it could lose a count on each reversal. But, then it ought to lose a count in the opposite direction when the spindle reverses again, correcting the first error. I have to admit I have not done peck rigid tapping, so I can't say if the same problem is happening on my machine. I have a fairly low encoder count on my Bridgeport, 324 counts in quadrature/rev. What is the resolution of your spindle encoder? I do lots of rigid tapping in aluminum with fairly small taps, 2-56 up to 10-32 or so. I have no issues with torque on these, and I only have a 1 Hp spindle motor and VFD. I do use Alum-Tap, which is a truly magic tapping fluid. You can EASILY feel the reduced torque when hand tapping aluminum, maybe half the torque as when using cutting oil. One other issue, could there be backlash in your Z drive? I have less than .0015" backlash in my Z drive. I can easily imagine Z axis backlash could be a greater issue than which side of the encoder pulse it is counting transitions on. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 5 axis cutter compensation
On 04/15/2021 03:30 PM, Stuart Stevenson wrote: Which EMC Corp sent the letter demanding the group stopped using EMC2? There are at least three now. https://www.dellemc.com/ A wing of Dell I think it is this one, I had no idea Dell bought them. I have no idea if Dell is as rabid at protecting their trademark as they were when they were EMC2 (squared). Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 5 axis cutter compensation
On 04/15/2021 12:36 PM, John Thornton wrote: Well it could be shortened to NEMC Nope, the dastardly EMC2 corporation would be all over us if we did that. That's why we had to change the name about a decade ago. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Home_use_index issue revisited
On 04/03/2021 11:39 PM, Sam Sokolik wrote: Initially I would just try 'and-ing' the 2 in hal or classic ladder and run strait to the home input. (Not using the home to index) If the prox sensor is of very short duration in linear motion, then the AND will just pop on for a moment, and likely go past it on the initial home search. That will likely confuse the homing sequence. But, you can try it. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Beagle Bone / PRU support ?
On 04/01/2021 03:36 AM, andy pugh wrote: On Thu, 1 Apr 2021 at 03:10, Alan Condit wrote: I have an extra BBB that is not in use. I would be happy to donate it to the project. Thanks. I do have a BBB, but it does not have OS / kernel set up for LinuxCNC. In fact it might never have been powered up. If one were to want to create user-downloadable kits for the Beagle Bone, Robert C. Nelson has already done it for Machinekit. One could either contact him or just take the script he uses. I think that script will run on any Linux host, but I've only run it on an X86 system. So, RCN has already done all the work for an installable distro. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Beagle Bone / PRU support ?
On 03/28/2021 09:46 PM, Gene Heskett wrote: I, for comparison, I just built the latest git pull on my pi4, getting these times, which I don't quite grok: real81m28.218s user133m40.185s sys 30m24.466s How do I get user+sys at nearly 2x the real which is the same as the actual wall time? Doesn't the Pi4 have multiple CPU cores? With 2 cores, total times can be 2X wall clock time. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Beagle Bone / PRU support ?
On 03/28/2021 04:18 PM, andy pugh wrote: On Sun, 28 Mar 2021 at 19:40, Jon Elson wrote: I was wondering if there was any possibility that LinuxCNC could support the Beagle Bone and Charles Steinkuehler's driver for the PRU. I have talked to Charles about it in the past (a few years ago) but wasn't really interested enough at the time to experiment. It looks like the code will just drop into the LinuxCNC tree. But it only compiles on the Beaglebone. I don't have one set up here at the moment. Right, it would take somebody to set up the infrastructure. If you want to try compiling this new branch: https://github.com/LinuxCNC/linuxcnc/tree/andypugh/bb_pru A problem is that with no BBB buildslave, no packages will be built by the buildbot. Compiling all of LinuxCNC on the Bone would not be as quick as on a decent X86 machine. I think it comes out maybe being 1/4 the speed. That's probably still OK, though. Thanks, Andy and Bari for the comments. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Beagle Bone / PRU support ?
On 03/28/2021 04:50 PM, Bari wrote: On 3/28/21 1:39 PM, Jon Elson wrote: I was wondering if there was any possibility that LinuxCNC could support the Beagle Bone and Charles Steinkuehler's driver for the PRU. This does software stepping with quite decent performance by moving the "base thread" into the PRU processors (200 MHz 32-bit RISC attached CPUs). This has been shown to work nicely for small stepper-driven machines. Not sure why the OrangePi LCNC project didn't just try to get this going on the Allwinners since they have an integrated micro for high speed stepping and a GPU to support a HD res 30+ fps GUI. https://orangecnc.gitlab.io/ Tom P did just post this work for Rpi and Opi's to do double stepping using the GPIO from the main CPU cores. Well, that's nothing like the PRU "driver" that Charles put together. It looks about the same as an X86 with at least a 20 KHz base thread. The Pi definitely has better graphics support than the Bone, but it is mostly tolerable. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Beagle Bone / PRU support ?
The Machinekit project seems to be very quiet. Maybe they think they accomplished all their goals. I was wondering if there was any possibility that LinuxCNC could support the Beagle Bone and Charles Steinkuehler's driver for the PRU. This does software stepping with quite decent performance by moving the "base thread" into the PRU processors (200 MHz 32-bit RISC attached CPUs). This has been shown to work nicely for small stepper-driven machines. Right now, Robert C. Nelson is providing a Machinekit build (equivalent to our iso's) but I don't know if that will continue indefinitely. Any comments? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] issues with 2.8.0-pre1
On 02/05/2021 01:32 AM, andy pugh wrote: On Thu, 4 Feb 2021 at 20:43, Jon Elson wrote: The automatic update of the .ini and .hal files crashed and left a big mess The originals should be backed up in a folder in the config folder. No problem, I had backups. Why are you using 2.8.0~pre1? Well, that's what I built when I was debugging the 64-bit issues in the ppmc driver, and it seems to work. I had to swap computers in the middle of a multi-day job and just wanted to get running quickly. After this job is finished, I can go in and clean up other issues. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] issues with 2.8.0-pre1
On 02/04/2021 03:49 PM, John Thornton wrote: If you could list the items that are not correct with the corrected information I can work on them. I searched for tons of places but nothing showed up... also if your looking at the html documents online the url would help me find the document with the error much faster. http://linuxcnc.org/docs/2.8/html/examples/mpg.html Shows controlling axis but not joint, so you can't use the mpg before homing. http://linuxcnc.org/docs/2.8/html/config/core-components.html Section 2. Axis and Joint Pins and Parameters is VERY terse, and there are no links to other info. I'm looking for the info on trivkins specifically about axis.x... and joint.n... This doc : http://linuxcnc.org/docs/2.8/html/hal/components.html in section 2.6 Kinematics mentions trivkins, but again, no list of pins and very terse description. Advanced Topics / Kinematics : http://linuxcnc.org/docs/2.8/html/motion/kinematics.html Gives some detail about the joints, but no mention of axis, and no description of hal pins. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] issues with 2.8.0-pre1
On 02/04/2021 02:42 PM, Jon Elson wrote: And, the second one is that before homing, my jog pendant works fine. AFTER homing all axes, it does not cause movement. I looked at : joint.0.jog-enable it goes true when the jog enable button is pressed joint.0.jog-scale it is 2.5x10^-5 (-r ^-6 or ^-7) depending on the jog rate selector joint.0.jog-counts it shows a large integer which changes as the jog dial is rotated. Aha, of course, you have to send the jogging command to both joint.0... and axis.x... if you want jogging in both modes. Which brings me to the point that the docs need a MAJOR update in regard to the axis/joint split. There are tons of places in the associated docs where they still show the old 2.7 behavior of things. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] issues with 2.8.0-pre1
My trusty computer on my Bridgeport started going flaky, so I put in the development computer I had used for PCIe and 64-bit testing. The automatic update of the .ini and .hal files crashed and left a big mess, so i had to do the joint conversion by hand. That all seemed to go well, but now I've seen two problems. When homing right after startup, I get intermittent "home switch inactive before start of latch move j=0" That could be some kind of timing issue, likely the old version didn't have this test. And, the second one is that before homing, my jog pendant works fine. AFTER homing all axes, it does not cause movement. I looked at : joint.0.jog-enable it goes true when the jog enable button is pressed joint.0.jog-scale it is 2.5x10^-5 (-r ^-6 or ^-7) depending on the jog rate selector joint.0.jog-counts it shows a large integer which changes as the jog dial is rotated. Any idea why homing the axes makes LinuxCNC no longer accept changes to jog-counts? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Minimum feed rate in G93
On 01/11/2021 01:30 PM, Robert Ellenberg wrote: I think the reason there are minimum feed rate (overall) is because motion / TP has a few places where it needs to detect if the machine is stopped, and the test has some numerical tolerance in it to avoid floating point weirdness. That said, there might be a way to design that kind of thing out should someone be suitably motivated. Well, there's a BIG difference between 0.1 IPM and +/- one LSB of a floating point number. Maybe the value to compare to could just be moved down a couple orders of magnitude. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Minimum feed rate in G93
On 01/11/2021 09:23 AM, Robert Ellenberg wrote: The good news is, I've got a fix that removes this restriction, and instead checks if the resulting feed rate is above the minimum that the rest of the system can handle (rebased onto 2.8): https://github.com/robEllenberg/linuxcnc-mirror/tree/hotfix/g93-minimum-feed-rate Thanks for working on it! But, why should there be any MINIMUM feedrate on any axis? With everything done in floats, I can''t see why there should be a minimum value. Maybe I am totally misunderstanding what has a forced minimum. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] What to do about the docs?
On 11/30/2020 01:07 AM, Gene Heskett wrote: And this has an encoder generating good quadrature signals optically, on the back end of the motor, from which the encoder module will output both position in counts (for comparison to SCALE) and velocity. Can I use both signals in 2 pid's in series? I've seen that mentioned in some of the searched for links with the claim that its much more stable that way. There's no need, and a lot of good reasons NOT to use two PIDs. The PID component DOES have a pin to accept a velocity input. I use this in my later PWM systems where the PPMC driver does output a smoothed velocity. And this particular driver doesn't seem to have a usable current sense output. Torque mode amps accept a command input and make the output CURRENT match that. If the servo amp is a VOLTAGE amp, then the tuning is a bit different, but may actually be easier than a torque mode system. That's what my PWM servo amps do. You want to tune first with FF1, with P set quite low. When error is reduced to a small amount with FF1 adjustment, then turn up P. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] What to do about the docs?
On 11/29/2020 08:09 PM, Gene Heskett wrote: But what characteristic is it that actually determines what sort of a servo it is? As in torque vs velocity? I intend for this to work under cutting loads. That is why the double reduction of two worm drives in series that this will be. A velocity servo has a speed sensing device (like a DC tachometer), the control sends a velocity command, the drive is supposed to make mechanical velocity exactly proportional to commanded velocity. A torque amp has a current sensing device (ammeter shunt) and the command from the control makes current proportional to the torque command. Motor torque should be very close to current except at the outer edges of the motor's curves. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] What to do about the docs?
On 11/29/2020 07:02 PM, Gene Heskett wrote: I should be at about the servo tuning step by this time next week, something I have only done with steppers, and likely at less than optimum settings. Is there a tut on adjusting such a servo? You could look at my page on servo tuning at : http://wiki.linuxcnc.org/cgi-bin/wiki.pl?PWM_Servo_Amplifiers It is aimed at my PWM controller/PWM servo amps, but generally goes through the steps. My procedure has evolved a bit. What I do is set I and D to zero and P low (5 - 50, depends on the system) and then adjust FF1 while observing pid.nn.error with Halscope, and also showing encoder velocity to have something for the scope to trigger on. When you get the error down to small value (.001" or less) then you may want to add a TINY amount of FF2 to help with the accel/decel transients. You have to find a compromise here, as friction helps with decel but hurts with accel. Then, turn up P until some oscillatory behavior appears, then add a little bit of D. If FF1 is good, then you don't need P to be real high to get good following. The general scheme changes a bit depending on whether it is a velocity servo, torque servo or a voltage servo that behaves kind of in between. With a true velocity servo, FF1 does almost all the work, and P can be quite low. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Pi crashed.
On 11/28/2020 04:16 AM, Gene Heskett wrote: [ 3661.143] (II) modeset(0): EDID vendor "ONN", prod id 257 [ 5461.166] (II) modeset(0): EDID vendor "ONN", prod id 257 Apparently is going to repeat until it crashes. Could be the monitor has crashed and is reporting invalid EDID numbers. Or, the cable has a dirty connection so the EDID info is getting corrupted. Just a thought... Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] CNC Controller
On 10/16/2020 07:11 AM, Matt Shaver wrote: >From the e-mail address, I would guess: http://www.jdsmotion.com/ Wow, Matt, I haven't seen you on in ages! Good to see you around! Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Wheezy install vs. editors
One of my customers is having issues with editing hal files. He says he is using the Wheezy iso install, and the only editor on it is "mousepad". Never heard of that. He reports that if he opens a hal file for editing, LinuxCNC/Axis will no longer come up. I remembered an issue about CR/LF being corrupted by editing some time ago, and suggested he download another editor, like emacs. He's going to try that, now. Has anyone seen this issue? Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.8 release update.
On 08/04/2020 10:10 AM, Gene Heskett wrote: On Tuesday 04 August 2020 08:10:48 Stuart Stevenson wrote: I saw no problems in config.log other than the configure report in the terminal. libgnomeprint-2.2 and optreset both are 'OLD' - I believe I can safely ignore both But I was talking about what goes flying by on screen while ./configure is running. Much more verbose than the log. You might have to set scrollback thru history to 50,000 or more to see the whole thing. But yes, libgnomeprint-2.2 is OLD. optreset I don't recall seeing so is new to me. You can do this : ./configure 2>&1 | tee configure.log This redirects both std output and error output to one pipe, and tees it so you see the output on the screen and it also writes to the file. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] problem understanding diagram from help-pages of pncconf
On 07/14/2020 11:00 AM, Reinhard wrote: Last weeks I worked hard on linuxcnc and the deeper I dig, the more upset I get. Such a great project and nobody cares about quality ... That makes me mad. ... and when I see such things like the homing maze ... That was too much Well, I've been using EMC/EMC2/LinuxCNC since 1998. There were some stability issues in 1997. But, since then, I have gone through 3 computers and a bunch of software updates, but LinuxCNC just works. I have NEVER, since 1998, had it crash on me. There have been a few issues, but they are all related to operator error of one kind or another. There has been some grumbling about the slow progress and long delays between updates, but it takes a while for issues to turn up and be fixed. So, I think that is the mark of quality -- take the time to be sure it is right before releasing it. Yes, the documentation doesn't look like the product of a billion $ corporation, but it is being supported largely by ONE GUY! And, we are so lucky to have John Thornton take over the docs, that ugly job that nobody else wanted to do! There is a REASON homing is complicated, there are situations where you NEED to do it in several different ways. Homing is needed for machines with tool changers, and accurate homing is needed where you will restart the machine with referenced fixtures in place, and expect the same reference as the day before. LinuxCNC does all this quite well. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] problem understanding diagram from help-pages of pncconf
On 07/14/2020 10:31 AM, Chris Morley wrote: I don't understand your hostility. I didn't create the homing routine but it seems reasonable to me. Linuxcnc is capable of doing exactly what you are used to, just set some of the settings to zero. There is a case where the home position MUST be different than the switch position. If you use a limit switch for home, then the home position MUST cause the machine to back away from the switch. Also, when using encoder index pulses to make the homing more repeatable, then the hole position will be slightly different from the point where the switch trips. You then have the choice for the axis to continue toward the switch, or to back away, while searching for the index pulse. I think all of these options are necessary for specific machine configurations. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] What to do about the docs?
On 07/12/2020 03:59 PM, Rod Webster wrote: Personally, I think the power of Google Translate makes this redundant. If I open a non-english HTML page Google Translate just translates it for me. I asked a French speaking person to review a 20 page technical document of mine which I had translated in Google Drive from English to French using Google Translate. He said there was nothing for him to do as it was perfect! WOW, I'm impressed, but still skeptical. Yes, computer translation has come a LONG way recently, but I'd still worry that something got horribly muddled. It may also depend a lot on the clarity of the original document. Maybe we should do a test and have Google translate our docs and then have it reviewed by a person who is both a native speaker of that language and fluent in CNC. They might catch a few howlers but still save a lot of effort. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] What to do about the docs?
On 07/12/2020 12:49 PM, andy pugh wrote: On Sun, 12 Jul 2020 at 18:44, Leonardo Marsaglia wrote: By the way. I second the dropping the PDF docs in favour of the HTML ones. It's much more easy to find the info in the HTML docs that I almost forget there are PDF docs uploaded. The PDF ones are added to the package by the build system. I don't _think_ that the HTML ones are. PDF docs are quite compact as files, and can be browsed with a low-footprint document reader. I think that's an advantage. The whole HTML doc system is getting to be a large file set and requires a browser that takes more resources. Some people may want to have the docs stored locally on their CNC control for quick reference. Some people are also leery of putting their CNC on the network, so local is the only way. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] What to do about the docs?
On 07/12/2020 10:52 AM, andy pugh wrote: On Sun, 12 Jul 2020 at 16:39, wrote: Go for it AndyP. Is this support for dropping the multilingual docs? Well, horribly out of date multilingual docs should maybe be removed from the main directory tree, but retained in git so if somebody so inclined wanted to work on it, it could be the starting point. Your suggested change to the directory tree seems to make sense. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Docs help required
On 07/08/2020 09:25 AM, andy pugh wrote: On Wed, 8 Jul 2020 at 12:27, John wrote: Odd, when I try and view a page on github I get a 404 page not found. https://github.com/LinuxCNC/linuxcnc/blob/andypugh/cn_docs/docs/src/getting-started/Master_Getting_Started_cn.txt The main page comes up, the linked pages there get the 404. It looks like the links don't work (I see no reason for those to be links at all, that is Github being too clever) You can find them here: https://github.com/LinuxCNC/linuxcnc/tree/andypugh/cn_docs/docs/src/getting-started Yes, this works on my system, and the documents give a mixture of English and Chinese text. Of course, I can't read the Chinese, but it does display. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] armhf master is ignoreing axis limits
On 07/05/2020 01:52 PM, Gene Heskett wrote: Greetings all; I see some fussing about jerky jogs so I thought I'd go check mine, starting with the Sheldon, which is driven by an rpi4b thru a 7i90 setup. Zero such problems, before or after homeing. Both the hand dials and the keyboard work smooth and well. But, while I have axis limits set in the armhf's .ini file, they are not only ignored, they don't show up in the halmeter or halshow lists. Can't say about master, but the general scheme is : both in [JOINT_#] and [AXIS_N] there should be a MIN_LIMIT and MAX_LIMIT. In a cartesian machine, these should be the same for corresponding joints and axes. Now, somehow, these get back to something, might be the trajectory planner(?) that is in userspace. So, there is no hal linkup to them. I've looked at a few other configs sets and the limits don't show up in their hal files, either. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.8 Situation
On 06/12/2020 04:03 AM, andy pugh wrote: Machinekit abandoned the idea of releases. I have heard that that makes it hard to find a version that actually works. Yes, my test fixture still uses a build set up by Matt Shaver quite a few years ago. But, then, Robert C. Nelson started building Beagle Bone kernel releases with machinekit pre-installed. I use these for a number of non-CNC projects, but also for at least one that does use the Machinekit variant of LinuxCNC for a one-axis positioner. As far as I know, this is still being built and up to date, there are links on the Machinekit web pages for how to download the entire install with machinekit. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.8 Situation
On 06/10/2020 09:33 PM, Reinhard wrote: RIP-installation? - wtf - I wanted to start with linuxcnc, not bring it to cementery RIP is "Run In Place". This allows you to have several versions of LinuxCNC on the same computer. It is usually used by developers who have compiled LinuxCNC from the source code. There is a script that sets up all the right environment variables to point to the right directories. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.8 Situation
On 06/10/2020 05:19 PM, Alec Ari via Emc-developers wrote: Paolo just emailed me and can't recreate the RTAI crash on his end. I asked about his configuration and I'll be trying a few more things. Yeah, I was afraid of that. He has some "magic sauce" in his systems that nobody else knows about. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.8 Situation
On 06/09/2020 03:07 PM, andy pugh wrote:
I have a simple test, but I am far from sure that it exercises the same bug.
#!/bin/bash
for PASS in $(seq 1 10); do
echo starting pass ${PASS}
insmod /usr/realtime-4.14.174-rtai-amd64/modules/rtai_hal.ko
insmod /usr/realtime-4.14.174-rtai-amd64/modules/rtai_sched.ko
rmmod rtai_sched
rmmod rtai_hal
done
( RTAI kernel and app packages exist in www.linuxcnc.org/temp )
So, this doesn't actually need the module to even be
executed! Just install the module and
then remove it, and rtai locks up eventually? Wow!
Jon
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.8 Situation
On 06/09/2020 10:03 AM, andy pugh wrote: On Tue, 9 Jun 2020 at 15:49, Jon Elson wrote: Now that you've narrowed it down to abs It's not abs. That's just the alphabetically first test. It crashes (more slowly) even if you just do realtime start / halrun -U in a loop. Ugh! Well, Paolo is then likely the only person who could debug it. And, as we know, progress there can be glacial. But, if you can strip the issue down to a simple test that only requires RTAI, maybe it'll get him motivated. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 2.8 Situation
On 06/09/2020 05:25 AM, andy pugh wrote: Specifically a script that starts realtime, loads an instance of the abs component and then exists will cause a kernel lock up after hundreds to thousands of cycles. Now that you've narrowed it down to abs (VERY good detective work, there!) you might look closely at the code used and see if it suggests anything funny. And, of course, you could send a message to Paolo to see if he has any ideas. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] PRs, CI, issue reporting
On 05/27/2020 11:41 AM, andy pugh wrote: On Wed, 20 May 2020 at 11:20, John Morris wrote: I see the GH org's repo has 281 branches. (!!!) Are all those branches inherited from glo (I see some of my own branches in there!), or are individuals still pushing directly to their own feature branches in the org's repo? I am wondering if it makes sense to remove some of the stale branches that contain work that we know has been merged. https://github.com/LinuxCNC/linuxcnc/branches/stale?page=1 Wow, some of these go back WAY before the EMC2 / HAL implementation. I guess somebody should go through them and see if there is anything that even applies to current branches, or has anything that might be of interest. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Sigma5ABS Implementation - Commutation
On 05/10/2020 10:20 PM, Curtis Dutton wrote: These do have hall signals to allow initial commutation. Ah, that solves the commutation issue. If you had to drive fanuc encoder/servos from a bldc component how would you (roughly speaking) configure them? Well, I don't. I make brushless servo amps that take the "Hall" signals to control commutation. So, they are simple six-step drives, not sinusoidal. But, that seems to work pretty well. There IS a slight discontinuity at the commutation changes, but it is really pretty small. So, for the Fanuc encoders, I make converters that provide simulated Hall signals from the information available. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Sigma5ABS Implementation - Commutation
On 05/10/2020 07:20 PM, Curtis Dutton wrote: I have been able to get the yaskawa sigma5 motors turning with the bldc component in qh mode. The encoders are a sort of hybrid incremental/absolute encoder. Once they pass the index point a flag and an offset are returned in the encoder data that allows the exact rotor angle position to be computed. I'm trying to find the best path forward for facilitating commutation. Any guidance would be appreciated. Fanuc has two types of serial encoders. ABS and INC, for absolute and incremental. The incremental type only provide correct shaft angle when battery backup is provided. If the battery is disconnected or drained, then you have to manually crank the motor over one full turn so the encoder can see the index position. Then, the controller can determine commutation from the encoder data. The absolute type have an additional low-res track that provides a 1024 count per quadrant data that is aligned to the motor poles, so a drive could immediately get commutation data when encoder power is on. Although Fanuc provides a backup battery for these encoders, it seems it is not totally necessary. Perhaps the Yaskawa also have provision for battery backup? The flag changing when index is sensed sounds just like what the Fanuc encoders do. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] startup anomaly on OLD LinuxCNC
On 05/06/2020 11:26 AM, Sam Sokolik wrote: I think the splash gcode sets the units to mm... So if your program doesn't change it back to inches you will get odd behavior... (I think) WOW, thank you! Yes, that could completely explain the behavior. I normally leave the machine in inch mode at startup, so I don't have it in my boilerplate header. I think that could explain ALL the cases where I have had something odd happen. (Anomalously slow motion was the other symptom I'd seen.) Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] startup anomaly on OLD LinuxCNC
Yes, I KNOW, this is a REALLY old version, but just thought I'd report it. I'm running LinuxCNC 2.5.4 on my Bridgeport mill. I just used it a couple days ago, everything worked fine. I started it up today, homed, and forgot to load the toolpath, and pressed R with the LinuxCNC toolpath still loaded. I immediately noticed it was heading for the wrong place and hit esc to abort it. I then loaded the correct .ngc file, and when I pressed R, it again headed toward (0,0). I reloaded the toolpath several times, getting the same response from that path and another old toolpath I tried. Finally, I exited LinuxCNC and restarted, homed, loaded the toolpath and all was fine. I believe I have experienced something like this behavior twice before, and never was able to put my finger on what was wrong. I am using the Axis GUI. Yes, someday I will update this system, but it does all I need right now, I don't do any LinuxCNC development on it, just cut metal. Thanks for any comments, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Third-Party GUIs
On 05/04/2020 09:01 AM, Sebastian Kuzminsky wrote: Last time I checked, which was very, very long ago, Machinekit had not replaced the NML system used to communicate between the LinuxCNC GUIs and the machine controller, they had just wrapped it in a new software layer. Did they get rid of NML and make their new wrapper be the whole thing? They replaced MANY of the functions with 0mq, but last I heard (also quite a while ago) it was not complete, so some of NML was still there. The MachineKit web site has certainly been updated recently. Also, there is some traffic on their forum. The Github is marked as "archived" and no pull requests will be accepted. That is a pretty bad sign, unless they have moved development somewhere else. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Third-Party GUIs
On 05/03/2020 07:26 AM, Robert Murphy wrote: Machinekit, IMHO, seemed to be focused more towards the hobbyist who wants bells and whistles rather than an industrial\commercial scene. Well, no. A major focus was to support multiple instances of Machinekit working in the same physical space, without interference. Think of workcells with part loaders, part unloaders and machining centers all moving through the same volume without anything hitting other machines. Or, multiple machines like robots that each do a specific job, like welding and drilling holes at the same time. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Third-Party GUIs
On 05/02/2020 05:13 AM, andy pugh wrote: On Sat, 2 May 2020 at 10:15, Phill Carter wrote: I really don't see a problem with having the UI's as part of LinuxCNC Many folk already complain that LinuxCNC is too difficult to set up. I think that we would lose a lot of new users at the point that they finished installing LinuxCNC and then found that they had to then go off and find and install a user interface. Yes, and another thing would be when something doesn't work. If we maintain a "standard" GUI, such as Axis, we could always tell them to try the same program or operation with Axis and see if you get a similar error. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/26/2020 01:01 PM, andy pugh wrote: On Sun, 26 Apr 2020 at 17:00, Jon Elson wrote: Also, this bug would have affected all 2.7.x versions installed on a 64-bit kernel. Should we backport the fixed version to them? Do you think that it is important enough to prompt an incremental 2.7 release? If not then it won't get out to users anyway. Well, I don't know what standard distros of 2.7.x were made with 64-bit kernels. If none, then there's no problem. It then could only affect people who built from source, and we can tell them how to fix it. If there IS a 2.7.x distro iso file with a 64-bit kernel, then it should be fixed. This bug is completely "fatal" on 64-bit compiles, as the encoder rolls over from 0 to -16777216 counts, causing an immediate following error. And, this affects all 3 of the Pico Systems devices. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 07:04 PM, andy pugh wrote: No, there is no 64-bit HAL pin to export the count on. So, if there's a move afoot to add s64 integers as a hal type, maybe we should merge my recent commit on hal_ppmc.c to master, and wait for the s64 variables to become available before extending the integer count to 64 bits. (Also, having a 64-bit integer makes it a LOT cleaner, I know how to do it with a pair of s32 integers, but doing all the carries across the words is just so much like the old 8-bit micro days.) Also, this bug would have affected all 2.7.x versions installed on a 64-bit kernel. Should we backport the fixed version to them? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 07:27 PM, Rod Webster wrote: I wondered how much effort there was in adding a new hal type. PCW has mentioned a string type would be helpful or him so If I were to dive in and add one type, it would not be hard to add an s64 as well. How hard would it be do you think to do that? I did have a bit of a peek at the source... It seems to touch a fair bit of stuff but not that hard I thought. Adding the type, ALONE, is trivial -- just about 4 lines in hal.h, I think. But, it would also be very useful to add this type into Halscope, Halmeter and Hal Configure, so you could inspect them. That still might not be so hard, but I'm guessing providing a wide enough field to print these or scale them onto Halscope could get pretty involved. Still, it seems like a good thing to have. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 02:51 PM, andy pugh wrote: On Sat, 25 Apr 2020 at 19:13, Jon Elson wrote: So, this Wiki page is the only place I know that tells how to do the whole process. Is this any good? http://linuxcnc.org/docs/2.8/html/code/building-linuxcnc.html Hmmm, that might have been helpful, but I wasn't able to find it on my own. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 01:24 PM, Jon Elson wrote: On 04/25/2020 11:52 AM, andy pugh wrote: So, swapping "long" for "int32_t" should make it work like it used to. Actually, it has to be hal_s32_t. The next question is whether you would prefer to store counts as 64 bits to be sure that nobody wraps an encoder while this universe exists. (the other encoder counters all use 64 bit accumulators) Yes, this is a good thought. But, since the current version exports a signed 32-bit raw count, changing this to 64 would make the change visible outside the driver. I'm not sure if anybody is actually using the exported raw encoder counts, though, so it might NOT make any difference. Then, of course, I'd have to test it on a 32-bit system, as well. Well, there doesn't seem to be a hal type for signed 64 bit integer! That seems to make what I'm trying to do impossible, unless I missed it (meaning that the full 64-bit signed integer raw count would be exported as a hal pin (mostly for me to test the thing!)) I did figure out a way to update the extended bits easily. instead of dealing with the extended 40-bit field as some separate entity, I just address the long form (64-bit) of the union like this :pos.l += 16777216; Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 11:52 AM, andy pugh wrote: So, swapping "long" for "int32_t" should make it work like it used to. Actually, it has to be hal_s32_t. The next question is whether you would prefer to store counts as 64 bits to be sure that nobody wraps an encoder while this universe exists. (the other encoder counters all use 64 bit accumulators) Yes, this is a good thought. But, since the current version exports a signed 32-bit raw count, changing this to 64 would make the change visible outside the driver. I'm not sure if anybody is actually using the exported raw encoder counts, though, so it might NOT make any difference. Then, of course, I'd have to test it on a 32-bit system, as well. 32-bits signed allows the encoder count to reach _2 billion and - 2 billion counts, so for a 1 million count/inch encoder you'd still have a travel limit of 2000 inches or 166 feet each side of zero. Maybe this change to a full 64-bit implementation could be pushed off until somebody actually asks for it. Also, the count rate limits on the PPMC devices makes it a bit less useful to have insane range on these position counts as it will take a LONG time to reach them. Well, I'm open to comments, and will have to study the code a bit more to see how hard this might be to implement. I did just commit and push the small version of this change, after testing it. Thanks for the help, guys! Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 12:33 PM, andy pugh wrote: On Sat, 25 Apr 2020 at 18:29, Jon Elson wrote: Seems like a problem with a preempt rt build -- or the instructions for it. Which instructions were you following? Ugh, there is a wiki page under "Installing linuxCNC" that has sections for many (old) systems. There a link at the top of the page, but it doesn't have info on compiling from source. So, this Wiki page is the only place I know that tells how to do the whole process. Anyway, I did manage to plunge through it and get it running. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 12:11 PM, Jon Elson wrote: On 04/25/2020 11:16 AM, Jon Elson wrote: And, now, debian/configure -r your kernel '4.9.0-8-rt-amd64' is not known. There might be needed dependencies which won't get set automatically. successfully configured for 'Debian-9.5'-'4.9.0-8-rt-amd64'.. and : dpkg-checkbuilddeps dpkg-checkbuilddeps: error: Unmet build dependencies: rtai-modules-4.9.0-8-rt-amd64 | rtai-modules-4.9.0-8-rt-amd64 This is a preempt install : Linux newcnc 4.9.0-8-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux So, these references to rtai seem like they are for the wrong kernel. Anyone know what to do at this point? OK, so I plunged ahead, did NOT install these packages, and LinuxCNC compiles and runs. Seems like a problem with a preempt rt build -- or the instructions for it. Now, on to fixing the actual error in the driver. Thanks to all! Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 11:16 AM, Jon Elson wrote: And, now, debian/configure -r your kernel '4.9.0-8-rt-amd64' is not known. There might be needed dependencies which won't get set automatically. successfully configured for 'Debian-9.5'-'4.9.0-8-rt-amd64'.. and : dpkg-checkbuilddeps dpkg-checkbuilddeps: error: Unmet build dependencies: rtai-modules-4.9.0-8-rt-amd64 | rtai-modules-4.9.0-8-rt-amd64 This is a preempt install : Linux newcnc 4.9.0-8-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux So, these references to rtai seem like they are for the wrong kernel. Anyone know what to do at this point? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 11:16 AM, Jon Elson wrote: On 04/25/2020 05:55 AM, andy pugh wrote: OK, I got the git clone to work. Now, I'm trying to compile the source. Is there a newer description for setting up Debian 9 to compile from source? The wiki page is from 2016. I got to sudo apt-get install libreadline5-dev and it couldn't find it. Ah, if you do it just by itself, it telly you this packaged has been replaced, and that seemed to work. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 05:55 AM, andy pugh wrote: OK, I got the git clone to work. Now, I'm trying to compile the source. Is there a newer description for setting up Debian 9 to compile from source? The wiki page is from 2016. I got to sudo apt-get install libreadline5-dev and it couldn't find it. Any ideas? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 06:11 AM, andy pugh wrote: On Sat, 25 Apr 2020 at 04:21, Jon Elson wrote: I immediately saw there were problems handling conversion to scaled position. I expected problems with the sign-extend/rollover of the 24-bit hardware encoder I might have already fixed the encoder rollover. git checkout git checkout origin/andypugh/ppmc_fix OK, so there's two parts. One is to handle the sign extension/rollover of the 24-bit hardware encoder to 32-bits. What I'm seeing so far (on 2.7.14) is that that IS working. But, then the 32-bit value is placed into a presumably 64-bit signed integer, while the upper 32-bits are allowed to stay at zero. So, minus numbers don't work. There are two ways to go. One is to make the extended 32-bit value explicitly 32-bits, as in int32_t. And, the existing code would just work fine, within its limits, incrementing and decrementing the uppermost byte. The other way is to handle it fully as a 64-bit signed value, and incrementing and decrementing the upper 40 bits. This would allow encoder counts up to 64-bits, although they could only be converted to float up to 55 bits, I think, before losing precision. One issue is the driver ecports a signed 32-bit raw encoder count. That would have to be changed to export a 64-bit count, and that's a change that could affect anyone using this hal pin. I have no way to know if anyone actually uses it, but I suspect it is a rare case. Now, if we go the 2nd way, with the signed 64-bit extended count, we need to be sure it compiles and runs correctly on both 32- and 64-bit systems. I'm kind of unfamiliar with handing 64-bit integers in the 32-bit C environment. But, I guess it is just supposed to work. Changing the count to a 64-bit integer will require a documentation change. Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Setting up to work on 64-bit driver issues
On 04/25/2020 05:55 AM, andy pugh wrote: That will work if your ssh keys are registered with LinuxCNC (and the keys on your current PC match) If that isn't the case it's not a big problem, you can instead use: This is a new install, so there are no ssh keys on it. I think this is the part that I always have a problem setting up right. Can anybody tell me how to set up the ssh keys on a new install so I can use it for push access? If there's a way to get the keys off the old computer I have that available. Is it just copying the files in the .ssh directory? Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Setting up to work on 64-bit driver issues
So, I finally got the decks cleared a bit, and want to work on the 64-bit issues in the Pico ppmc driver. I got the amd64-r13 installed and running, after some network issues. I immediately saw there were problems handling conversion to scaled position. I expected problems with the sign-extend/rollover of the 24-bit hardware encoder counter to signed 32-bit integer, but what I saw instead was as soon as you passed zero it jumped to -4294967295. So, at least this first look shows it is getting a proper signed 32-bit value and then improperly converting to float. Once I get into the code, it should be obvious what to do. So, that brings me to : Can anyone suggest the steps to set up the source for master - I do have a developer account on git. But, I'm guessing there have been some changes since I last was editing the driver source. This is a completely new install, so I have to get through setting up git for master with push access. I've always struggled with that. Thanks, Jon ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
