. .
Page 3 of 5 FirstFirst 12345 LastLast
  1. #21
    m_c's Avatar
    Lives in East Lothian, United Kingdom. Last Activity: 4 Days Ago Forum Superstar, has done so much to help others, they deserve a medal. Has been a member for 9-10 years. Has a total post count of 2,908. Received thanks 360 times, giving thanks to others 8 times.
    Quote Originally Posted by Kitwn View Post
    I'm sure you would have many grateful readers of a detailed write up on that. Me among them.

    Kit
    The condensed version.

    At the start we have the Trajectory planner, that takes the raw g-code, applies the machine parameters (acceleration, max speed, tolerances etc), and generates lots of little movement segments, with the time frame that those segments have to happen.

    Those little segments then go to the motion controller, which generates the physical steps that cause the machine to move. The trajectory planner might output 1mm segments, it's up to the motion controller to convert those 1mm segments into step/dir pulses.


    The motion controller is the time critical part of the process. The TP isn't. You could quite realistically run the TP and generate a huge buffer when you load your g-code, but I'll get on to that.
    Now this is where real-time OS's come in. The real benefit of a RTOS, is it's deterministic, aka you know exactly when things will happen. If you want something to happen in 20uS time, it'll happen then. System interrupts won't stop that from happening in 20uS time. Another process using processor time won't stop that happening in 20uS time. It will happen in 20uS, which is something you can't guarantee in Windows, as it is not a RTOS.
    This is how the core of LinuxCNC works, with the priority being updating the IO. The GUI has no priority over the IO, and can cause the screen to appear to crash during highload situations, as processing is directed to keeping the machine moving, not updating the screen.

    Now the way Mach got around this problem, was Art essentially hacked the windows kernel, and attached a deterministic interrupt to drive the parallel port.

    The limitation for both systems is you can only service the parallel port at a fixed speed, which is why you'll see lots of pulse jitter at certain speeds, as the motion controller fits the number of pulses needed to the available refresh rate (I.e. if you need 24'999Hz pulses, and you update speed is 25'000Hz, the only way to achieve that is to seemingly randomly drop a pulse and have a single pulse every 24'999 pulses that is twice the length of others).


    To keep the motion controller going, it needs a regular stream of segments, which is why the TP creates a buffer. Due to the often complex nature of trajectory planning, some moves can take a lot of processing power, so you never want the risk of the MC becoming starved of moves, as the only option then is for things to grind to an abrupt halt.
    As I've mentioned you could quite realistically buffer the entire g-code on loading, and provided nothing changes, everything would work perfectly well.

    However, what if something changes. You hit Pause, or adjust a FRO?
    This is where things get very murky.
    You either need the MC to handle it directly using what parameters it knows, but that may result in moves out of tolerance, or for the TP to update the buffer.
    How smoothly this happens, relies on how well integrated the TP and MC are, which for Mach with a parallel port, or LinuxCNC they are integrated and interact well.

    However, this is where Mach3 falls down quite spectacularly using certain external motion controllers. Due to it's 10Hz update cycle, you have one delay as the MC updates Mach that something needs changed, Mach then has to implement that change by re-generating the motion buffer in a controlled fashion, then push the new buffer out to the MC, which it often doesn't have the ability to flush, so you have to wait for the previous buffer to be used before the adjustment physically happens. Have a 2 second buffer, and you're going to be waiting 2 seconds for that change to happen. Have a 0.1sec buffer, and you're very likely to suffer from regular buffer underrun errors.

    Something else worth being aware off, is when using the parallel port, is each update takes a fixed amount of time. And that is time the computer won't be doing anything else, and is why there are limits on parallel ports speeds, although admittedly with modern processing speeds, it's much less of an issue.
    Avoiding the rubbish customer service from AluminiumWarehouse since July '13.

  2. The Following 4 Users Say Thank You to m_c For This Useful Post:


  3. #22
    m_c,
    Thank you so much for that, it's cleared up a lot including exactly what Clive S meant in this comment from a thread I started last year...

    "I am not sure why you sure why knocking linuxcnc saying that it "especially one requiring an antiquated parallel port" as that is not true. Stick any Mesa card in it and you will have pulse timing as fast and accurate as you will need. If you want Ethernet connected card then use a 7i76e card."

    I've had a look around for information on using LinuxCNC with a MESA card and came across a YouTuber called Marco Reps in Germany. Slightly eccentric (I liked him immediately) he has an interesting video on exactly that. It drags on a bit (14 mins) and the first minute or so are not relevant but he goes on to describe some of the tools in LinuxCNC which I had no clue about, some of which are only used when tuning servo drives. He recommends the MESA 6i24 card

    Kit

    PS I should probably appologise to Voicecoil for starting what has amounted to a complete hijack of his original thread.
    An optimist says the glass is half full, a pessimist says the glass is half empty, an engineer says you're using the wrong sized glass.

  4. #23

  5. #24
    m_c's Avatar
    Lives in East Lothian, United Kingdom. Last Activity: 4 Days Ago Forum Superstar, has done so much to help others, they deserve a medal. Has been a member for 9-10 years. Has a total post count of 2,908. Received thanks 360 times, giving thanks to others 8 times.
    It's worth mentioning that the parallel port was a good option for many years, and is more than adequate for the vast majority of machines. The main reason I wouldn't recommend it now, is there are too many potential issues in getting it working. You need a suitable motherboard. You've got to make sure the port settings are correct. You've got to hope Mach/LinuxCNC will play nicely with the motherboard. In the case of Mach, you need a suitable version of Windows.
    None of which are insurmountable, but it's all things that can potentially add additional time and cost to getting a machine running.

    To me, it's worth spending the extra money on a dedicated motion controller, as it removes quite a bit of uncertainty from the setup process. Plus it usually means you get improved support to get it working in the first place.

    I wouldn't get too hung up on the ideal theoretical option, as in practise, and as the parallel port proves, things can still work very well even if they're far from theoretically ideal.

    Servo tuning is whole other topic, but most closed loop capable controllers will have some form of tuning tools available. Dynomotion/KFlop tools are pretty advanced, and let you plot/adjust all sorts of things. CS-labs include a tuning screen, but IIRC it's pretty basic. Galil you have to buy their GDK to get servo tuning.
    Avoiding the rubbish customer service from AluminiumWarehouse since July '13.

  6. #25
    Oh yeah! I forgot the link! The video I watched is this one https://www.youtube.com/watch?v=1dy8Dgzcgq4

    Thanks mekanik.
    An optimist says the glass is half full, a pessimist says the glass is half empty, an engineer says you're using the wrong sized glass.

  7. #26
    m_c,
    Maybe I got lucky, but never had any trouble getting things working with the parallel port and LinuxCNC. I think some people have had trouble with add-on parallel cards rather than using an old mobo with it built in and I do remember some problems when I tried to use the on-board graphics of my current board rather than a separate card after the graphics card failed.

    I've been using the same old PC and cheap chinese parallel break-out board since I built my forst 'proof-of-concept' machine out of scrap and the cheapest components I could buy and am still entirely happy with it. LinuxCNC is the only software I've ever used and have no desire to change if I can avoid it.

    The risk with this approach is the lack of quick recovery from a computer failure. Not a problem for a pure hobbyist like me at present but for someone taking paid commissions the ability to grab any current motherboard, load the software, copy the .hal and .ini files (everyone DOES have a safe copy of those don't they?) and be confident of geting back in production is important. An external controller using a USB or Ethernet connection from the controlling computer is going to be a more reliable option in that regard.

    Kit
    An optimist says the glass is half full, a pessimist says the glass is half empty, an engineer says you're using the wrong sized glass.

  8. #27
    Quote Originally Posted by Doddy View Post
    We need to petition CNCDrive to port UCCNC to Linux :-)
    Well I did just that, and Balazs said he'd canvassed opinion on making it OS independent a year or so back, but didn't have much in the way of a response, and hence dropped the idea as it promised to be a lot of work.

    I have the SAS on standby to recapture my hijacked thread (lol) - and did find this which could be a solution:
    https://www.youtube.com/watch?v=R3g8VtJUdb4
    Last edited by Voicecoil; 12-10-2019 at 04:28 PM.

  9. #28
    Aha, didn't notice the "plus" range. Okay, one in the post and I'm going to try a LinuxCNC / parallel-port install.

    If you'd like I'd be happy to try installing UCCNC in demo mode prior to the linux install, to understand any installation issues, though with the licensing I don't think I'll be able to drive my mill directly - but I think if the demo works then it should be just about there.
    Last edited by Doddy; 12-10-2019 at 05:23 PM.

  10. #29
    Quote Originally Posted by Doddy View Post
    Aha, didn't notice the "plus" range.
    They give you rather more room to fit an HDD and if you wanted to run LinuxCNC using one of the Mesa controllers that has a PCI card, then there's room for that as well. However I suspect with a suitable compact operating system (i.e. not full Windoze 8/10) and using the machine purely for running the CNC, a 16GB flash DOM would likely suffice.
    If you'd like I'd be happy to try installing UCCNC in demo mode prior to the linux install, to understand any installation issues, though with the licensing I don't think I'll be able to drive my mill directly - but I think if the demo works then it should be just about there.
    That would be cool, thanks.
    Last edited by Voicecoil; 12-10-2019 at 07:51 PM.

  11. #30
    , a 16GB flash DOM would likely suffice.
    I used to run my Warco on a 8GB DOM using linuxcnc I still run it on the lathe. plugged into a small MB. I am following this thread with interest
    ..Clive
    The more you know, The better you know, How little you know

Page 3 of 5 FirstFirst 12345 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 4
    Last Post: 15-08-2016, 03:30 PM
  2. Machining thin Balsa
    By Nthkentman in forum Woodwork Discussion
    Replies: 3
    Last Post: 05-04-2015, 08:37 PM
  3. RFQ: RFQ: Need some thin aluminium cutting
    By stewpid22 in forum Projects, Jobs & Requests
    Replies: 0
    Last Post: 21-09-2012, 01:11 PM
  4. Replies: 5
    Last Post: 15-04-2012, 12:36 PM
  5. Looking for thin plastic? sheet
    By irving2008 in forum Machine Discussion
    Replies: 19
    Last Post: 09-09-2010, 12:32 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •