Re: [Emc-users] One servo system
Machinekit + PocketBeagle is good combo if you are looking for something running Linux. Chris Albertson writes: > Of course. Write a PID based control loop and put it an something > like an Arduino. I've done this a few times the control the wheels of > a mobile robot. > > The details depend on the interfaces to botkhthe motoring the higher > level control > > > As for higher level control... Is it a human using a joystick or some > kind of automation that does the same thing repetivity or must the > device interact with the environment some how. Perhaps opening a for > as a person approaches. > > Then I have to ask what kind of hardware driver you have. Some > drivers do most of the work for you. These might take a > step/direction pulse, r have an analog input. But other drivers are > just an H-Bridge and raw encoder signals.This is the kind of > serves I use. I end u using a small micro controler (Arduino or > ARM-M) and relaying on a PID library. > > In ant case most of your effort will be spent in the interfaces not > the actual PID control loop as that is just a few calls to a PID > library > > On Wed, Mar 28, 2018 at 8:15 AM, Marius Liebenberg > <mar...@mastercut.co.za> wrote: >> Hi all >> I have to put together a system that will use one servo to drive a small >> platform over a distance of 6m at a speed of about 25km/h or 8m/s or there >> about. >> >> I feel that using a full computer and mesa card for just one axis that does >> not need a display sounds a bit excessive. The question is what are the >> other options if any. >> >> >> >> - >> Regards / Groete >> >> Marius D. Liebenberg >> +27 82 698 3251 >> +27 12 743 6064 >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users -- Alexander Rössler HMI Expert at Rössler Systems Tel: +43 680 1348338 Web: https://roessler.systems Blog: https://machinekoder.com alexander@roessler.systems Lebnergasse 1/7/7 1210 Wien - Austria ATU72251528 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Anyone interested in QtQuickVcp support for LinuxCNC? (still the same)
Nicklas Karlsson writes: > Yes. I do not like python and guess C++ execute faster so why not. > > >> From a developers perspective VCPs where completely outdated and not >> even close to what modern UI toolkits offer. No developer really want's >> to work with tk, we can argue about Gtk2. > > I worked with glade and it works rather well although some of widgets > are a little bit limited. Yeah, widgets technology is great for small desktop UIs. However, I also seen big UIs where glade in general is bit of a pain. The more modern Gtk3 UIs also HTML/JS I have heard. > >> QtQuickVcp comes with 2 reference UIs: >> - Cetus: designed as axis replacement: >> https://github.com/qtquickvcp/Cetus > > Look the same as now so I guess it should work great. > >> To simplify remote deployment of the UIs one can simply download and run >> the "MachinekitClient" (yes, it's Machinekit only right now) and connect >> to the machine instance. >> >> This way, it's extremely simple to circumvent the limitations of >> embedded computers with weak graphics performance. Use a cheap 100$ >> tablet as your display and you are fine >> (https://www.youtube.com/watch?v=LnJv07yeGt0) > > The way I am heading. > >> To support LinuxCNC would be quite simple. The machine/server part is >> based on Machinetalk - an open source middleware. > > Linuxcnc use NML and I think the server part is in working order but have not > had enough time to figure out how it is with the "axis" user interface, got > more hardware today. > >> Basically, it would be a matter of "adapting" mkwrapper, mklauncher and >> configserver (Python applications) over to LinuxCNC. > > ? These are the names of the "server" applications in Machinekit. To make it simple: It would be possible to add the Machinetalk support as a separate package. No need to modify the LinuxCNC source code. > >> HAL Remote - which is useful for custom extensions would require more >> effort, since it depends on the haltalk server - which goes deep into >> Machinekit. > > haltalk, this is between which parrts. Very well described here: https://machinekoder.com/machinetalk-explained-part-4-hal-remote/ > >> From the user perspective, I think the split between LinuxCNC and >> Machinekit makes absolutely not sense and is very confusing. To make it >> simple: Machinekit is focused on Non-CNC and LinxuCNC on CNC. > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Anyone interested in QtQuickVcp support for LinuxCNC?
Remote UI is part of QtQuickVcp, so yes it would be supported. I can also post on the developers list. Rene Hopf writes: > Hi, > > Im very interested in using this. would you only port the qtvcp, or also the > remote UI stuff? or does that go together? > Norbert, the gmoccapy guy, is very interested in qt5. but he is only on the > developers list. > > Rene > >> On 21. Nov 2017, at 11:31, Alex Rössler <a...@machinekoder.com> wrote: >> >> Hello everyone, >> >> I have started a new VCP project approximately 4 years ago because I was >> very dissatisfied with what was already available in LinuxCNC at the time. >> >> From a users perspective, the UIs were not usable for 3d printers and did >> not even come close anything visually acceptable by the post-smartphone >> era customers. >> >> From a developers perspective VCPs where completely outdated and not >> even close to what modern UI toolkits offer. No developer really want's >> to work with tk, we can argue about Gtk2. >> >> From an OEM perspective, there was no option to build a close-source UI >> on top of LinuxCNC without a lot of effort. Additionally, if the OEM >> decides to stay with Gtk2, it's not supported anymore and (almost) no >> commercial help available. >> >> That's why I started a completely new approach for creating a VCP >> development kit based on QtQuick - which is Qt's UI development >> technology. >> >> QtQuickVcp comes with 2 reference UIs: >> - Cetus: designed as axis replacement: https://github.com/qtquickvcp/Cetus >> - Machineface: a generic and full-blown 3D printer UI: >> https://github.com/qtquickvcp/Machineface >> >> I agree both are not top notch when it comes to UI design. But with a >> little effort you can create great stuff with QtQuickVcp >> https://www.youtube.com/watch?v=uT-tAweP21U >> >> All UIs run on Linux, Windows, OSX, Android and iOS (not in the app >> store). >> >> To simplify remote deployment of the UIs one can simply download and run >> the "MachinekitClient" (yes, it's Machinekit only right now) and connect >> to the machine instance. >> >> This way, it's extremely simple to circumvent the limitations of >> embedded computers with weak graphics performance. Use a cheap 100$ >> tablet as your display and you are fine >> (https://www.youtube.com/watch?v=LnJv07yeGt0) >> >> To support LinuxCNC would be quite simple. The machine/server part is >> based on Machinetalk - an open source middleware. >> >> Basically, it would be a matter of "adapting" mkwrapper, mklauncher and >> configserver (Python applications) over to LinuxCNC. >> >> HAL Remote - which is useful for custom extensions would require more >> effort, since it depends on the haltalk server - which goes deep into >> Machinekit. >> >> From the user perspective, I think the split between LinuxCNC and >> Machinekit makes absolutely not sense and is very confusing. To make it >> simple: Machinekit is focused on Non-CNC and LinxuCNC on CNC. >> >> Anyway, that's worth another discussion, but for a start it would be >> great if we could unity the UI land at least. >> >> UI is driving factor for modern CNC and QtQuickVcp makes it possible to >> create modern UIs for LinuxCNC. >> >> Requiring the Qt toolchain, which can be cumbersome to install, is not >> an issue anymore thanks to live coding support: >> https://www.youtube.com/watch?v=B5rYhq06wio >> >> Stay tuned: I also have tools for drag and drop UI and machine creation in >> the >> making - because I think that's what made Mach3 so successful (despite >> the motion control is crap). >> >> Also upcoming thanks to Qt: Web Browser support: >> http://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/ >> >> If there is enough interest, I will start porting the required tools. >> >> -- >> Alex Rössler aka. Machine Koder >> https://machinekoder.com >> a...@machinekoder.com >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users > > > -- > Check out the vibrant tech community on o
Re: [Emc-users] Anyone interested in QtQuickVcp support for LinuxCNC?
I think Qt is a good choice for modern UIs. * It has a history of more than 21 years. * It's used on safety critical environments (medical, automotive, ...) * It supports all relevant platforms. * It's open source. * Commercial support is available if necessary. * QtQuickVcp is already working fine, no need to reinvent here. John Dammeyer writes: > There are rumours that RAD Studio will soon have a Linux Platform added to > their PC/Android/Apple Platforms. For those who don't know, the languages > supported are Delphi (think Skype, Altium CAD etc), and C++. Although it's > not a free development environment, the up side is with the click of a > selection in a drop down menu the target can be recompiled for any of the > platforms. That potentially makes it possible to develop a common user > interface for both local and remote control. And visual interfaces are > really easy to develop. > > I've done some remote control applications that run on both a PC Windows > Platform and my Android Tablet via Ethernet to DMX512A hardware. Simple > sliders for RGB control. > > In the long run this may be a better way to develop an updated user interface > for LinuxCNC. But I think it's still early days. > John > > > >> -Original Message- >> From: Alex Rössler [mailto:a...@machinekoder.com] >> Sent: November-21-17 2:32 AM >> To: Enhanced Machine Controller (EMC) >> Subject: [Emc-users] Anyone interested in QtQuickVcp support for LinuxCNC? >> >> Hello everyone, >> >> I have started a new VCP project approximately 4 years ago because I was >> very dissatisfied with what was already available in LinuxCNC at the >> time. >> >> From a users perspective, the UIs were not usable for 3d printers and >> did >> not even come close anything visually acceptable by the post-smartphone >> era customers. >> >> From a developers perspective VCPs where completely outdated and not >> even close to what modern UI toolkits offer. No developer really want's >> to work with tk, we can argue about Gtk2. >> >> From an OEM perspective, there was no option to build a close-source UI >> on top of LinuxCNC without a lot of effort. Additionally, if the OEM >> decides to stay with Gtk2, it's not supported anymore and (almost) no >> commercial help available. >> >> That's why I started a completely new approach for creating a VCP >> development kit based on QtQuick - which is Qt's UI development >> technology. >> >> QtQuickVcp comes with 2 reference UIs: >> - Cetus: designed as axis replacement: >> https://github.com/qtquickvcp/Cetus >> - Machineface: a generic and full-blown 3D printer UI: >> https://github.com/qtquickvcp/Machineface >> >> I agree both are not top notch when it comes to UI design. But with a >> little effort you can create great stuff with QtQuickVcp >> https://www.youtube.com/watch?v=uT-tAweP21U >> >> All UIs run on Linux, Windows, OSX, Android and iOS (not in the app >> store). >> >> To simplify remote deployment of the UIs one can simply download and run >> the "MachinekitClient" (yes, it's Machinekit only right now) and connect >> to the machine instance. >> >> This way, it's extremely simple to circumvent the limitations of >> embedded computers with weak graphics performance. Use a cheap 100$ >> tablet as your display and you are fine >> (https://www.youtube.com/watch?v=LnJv07yeGt0) >> >> To support LinuxCNC would be quite simple. The machine/server part is >> based on Machinetalk - an open source middleware. >> >> Basically, it would be a matter of "adapting" mkwrapper, mklauncher and >> configserver (Python applications) over to LinuxCNC. >> >> HAL Remote - which is useful for custom extensions would require more >> effort, since it depends on the haltalk server - which goes deep into >> Machinekit. >> >> From the user perspective, I think the split between LinuxCNC and >> Machinekit makes absolutely not sense and is very confusing. To make it >> simple: Machinekit is focused on Non-CNC and LinxuCNC on CNC. >> >> Anyway, that's worth another discussion, but for a start it would be >> great if we could unity the UI land at least. >> >> UI is driving factor for modern CNC and QtQuickVcp makes it possible to >> create modern UIs for LinuxCNC. >> >> Requiring the Qt toolchain, which can be cumbersome to install, is not >> an issue anymore thanks to live coding support: >> https://www.youtube.com/watch?v=B5rYhq06wio >> >> Stay tuned: I also have tools for drag and drop UI and machine creation >> in the >> making - because I think that's what made Mach3 so successful (despite >> the motion control is crap). >> >> Also upcoming thanks to Qt: Web Browser support: >> http://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/ >> >> If there is enough interest, I will start porting the required tools. >> >> -- >> Alex R�ssler aka. Machine Koder >> https://machinekoder.com >> a...@machinekoder.com >> >>
Re: [Emc-users] Anyone interested in QtQuickVcp support for LinuxCNC?
Sebastian Kuzminsky writes: > On 11/21/2017 03:31 AM, Alex Rössler wrote: >> Hello everyone, > > Hi Alex, > > >> I have started a new VCP project approximately 4 years ago because I was >> very dissatisfied with what was already available in LinuxCNC at the time. >> >> From a users perspective, the UIs were not usable for 3d printers and did >> not even come close anything visually acceptable by the post-smartphone >> era customers. >> >> From a developers perspective VCPs where completely outdated and not >> even close to what modern UI toolkits offer. No developer really want's >> to work with tk, we can argue about Gtk2. > > More UIs and UI frameworks are always welcome. > > >> From an OEM perspective, there was no option to build a close-source UI >> on top of LinuxCNC without a lot of effort. Additionally, if the OEM >> decides to stay with Gtk2, it's not supported anymore and (almost) no >> commercial help available. > > I am not at all interested in closed source UIs, or closed source > software in general. > > The whole point of the LinuxCNC project as far as I'm concerned is to > produce open source machine control software; anything that's not > directly aligned with that goal is at best distraction to me. > > I understand that not everyone agrees with my opinion on this topic, and > I hope we can make progress on the technical aspects without getting > bogged down in a political/philosophical conversation. Yes, I agree here. Open source software is important but I also think it is important to support close-source use-cases. Closing down the UI is common way for OEMs to "protect" their products and corporate design from piracy/fakes on the market. > > >> That's why I started a completely new approach for creating a VCP >> development kit based on QtQuick - which is Qt's UI development >> technology. > > Awesome! > > >> QtQuickVcp comes with 2 reference UIs: >> - Cetus: designed as axis replacement: https://github.com/qtquickvcp/Cetus >> - Machineface: a generic and full-blown 3D printer UI: >> https://github.com/qtquickvcp/Machineface >> >> I agree both are not top notch when it comes to UI design. But with a >> little effort you can create great stuff with QtQuickVcp >> https://www.youtube.com/watch?v=uT-tAweP21U >> >> All UIs run on Linux, Windows, OSX, Android and iOS (not in the app >> store). > > How does the UI reach from the machine it's running on to the machine > running the motion controller? I understand that it's using some > innovation from Machinekit, but does it still end up talking to Task > using NML in the end? I haven't been following Machinekit at all so I > dont know what architectural changes y'all have made. If it ends up > being NML to Task we can probably support it in LinuxCNC. Machinetalk is the name of the middleware: https://machinekoder.com/machinetalk-explained-part-1-introduction/ Its Machinekit independent and does support multiple languages and platforms. > > >> To simplify remote deployment of the UIs one can simply download and run >> the "MachinekitClient" (yes, it's Machinekit only right now) and connect >> to the machine instance. > > So MachinekitClient is some kind of generic UI-running application, sort > of like a web browser, and the UIs are runtime-loadable front ends sort > of like web pages? That's exactly the idea. > > >> To support LinuxCNC would be quite simple. The machine/server part is >> based on Machinetalk - an open source middleware. >> >> Basically, it would be a matter of "adapting" mkwrapper, mklauncher and >> configserver (Python applications) over to LinuxCNC. >> >> HAL Remote - which is useful for custom extensions would require more >> effort, since it depends on the haltalk server - which goes deep into >> Machinekit. > > This to me seems like the bulk of the work. > > Remote UIs need a way to talk to the motion controller, and I understand > the interfaces available for this in Machinekit are far different from > what we have in LinuxCNC. We have working NML-over-TCP, but no MDNS-SD > auto-discovery and no remote HAL interface (halrmt doesn't count). So, the story is the following. NML is not replaced yet in Machinekit. For the CNC relevant interface we use wrappers around the linuxcnc Python module. So we should be pretty compatible with LinuxCNC when it comes to supporting the CNC UIs. Machinetalk can be packaged independently. Easiest way to install it is via Python pip. pip install machinetalk-protobuf > > >> From the user perspective, I think the split between LinuxCNC and >> Machinekit makes absolutely not sense and is very confusing. > > I agree with this statement, but it's another tangential topic that I > will stay out of, because it threatens to distract from the productive > technical conversation. > > >> Requiring the Qt toolchain, which can be cumbersome to install, is not >> an issue anymore thanks to live coding support: >> https://www.youtube.com/watch?v=B5rYhq06wio > > What Linux distros can you
Re: [Emc-users] beaglebone black
andy pugh writes: > On 21 November 2017 at 02:57, a k <pccncmach...@gmail.com> wrote: >> i am interesting in beaglebone black board BBB and in book >> --beaglebone for dummies--i found there about desktop five axis cnc mill >> this book also available for free in PDF format for download. >> about www.pocketnc.com >> and >> http://beagleboard.org/project/pocketnc >> >> can linuxcnc run on BBB board? and be so compact? > > Yes, PocketNC uses LinuxCNC. As far a I know they use Machinekit - which is a fork of LinuxCNC with special additions for embedded Linux devices such as a HAL driver for the BBB -- Alexander Rössler -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Waiting for cycle start in MDI command
On 2016-11-21 11:19, andy pugh wrote: > On 21 November 2016 at 09:48, Alexander Rössler <mail@roessler.systems> > wrote: >> I have the following problem: >> The machine requires the user to press a cycle start (physical button) >> on the machine before executing an MDI command. > > Which UI are you using? Perhaps you can just make the "Execute" button > invisible? It is a custom UI which I'm building. The idea is that the user has to press cycle start after entering the MDI command. 1. enter MDI and accept (clicking execute or pressing return) 2. press cycle start on the machine 3. run MDI command for normal programs I just add the wait-for-cycle-start GCode to the start of the program. For MDI commands it is more complicated it seems. Of course, I could handle everything in the UI. However, since this is a safety critical feature I think it would be better to implement this in HAL or as GCode command. > > Or am I misunderstanding the problem? -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Waiting for cycle start in MDI command
Hi all, I have the following problem: The machine requires the user to press a cycle start (physical button) on the machine before executing an MDI command. So far I have used a remap command to achieve this. Basically, I prefix this command to all MDI commands executed by the user. E.g.: M100 G0 X100 The M100 command waits for a digital input to toggle and aborts if it does not happen in a certain time frame. However, some GCode words take precedence over my remap command. In particular the S and T words. I have tried to use a Python prolog instead, which seems to always be executed before the other words in the MDI line. However, I cannot wait for something in the prolog because it freezes the interpreter. According to the docs one can use yield to pause a Python remap command. I also have tried this, but it seems the interpreter continues the execution after the prolog, which makes this approach useless for me. So my question here: Is there any other way to achieve this? I see following possible solutions to solve this problem: * create small multi-line programs from the MDI commands * handle wait-for-cycle-start in the UI Both solutions sound very hacky to me. Does anyone know any other method to delay the execution of MDI commands? The MDI commands are entered by the user, so I cannot use halui in this case. Cheers, Alexander -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Changing rapid traverse rate at run-time
On 2016-10-25 20:32, Chris Radek wrote: > On Tue, Oct 25, 2016 at 11:09:04AM +0200, Alexander R??ssler wrote: >> Is there a way to change the rapid traverse rate (G0) ate run-time? >> Preferably without touching NML... > > You can choose from the Rapid Override slider (percentage) and the > Max Velocity slider (velocity cap). > > If neither of these work for your application, tell us more! Rapidrate is probably what I'm looking for. Is this command new? -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Changing rapid traverse rate at run-time
Is there a way to change the rapid traverse rate (G0) ate run-time? Preferably without touching NML... Thanks, Alexander -- The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Serial FPGA buses/interconnections [Was: Sandy box]
Thats what crowdfunding is made for. Think about solutions, not problems. On June 7, 2015 1:06:00 AM CEST, Gene Heskett ghesk...@wdtv.com wrote: On Saturday 06 June 2015 16:52:08 Dave Cole wrote: I've been around for a while and worked with current loop serial interfaces, rs232, rs422/485, Ethernet (back when thicknet was standard) etc. Why in world would you not use Ethernet??It leaves you with so many options that are not available with RS485. I would join the Ethercat group, pay them some $$, get some source code and use what has already been developed and use every tool that they have already developed. No need to reinvent the wheel. Dave All well and good Dave, but how do we, in a cashless group, manage to find the sheckles to pay for a seat at that table? And how much is that seat, one time or annual dues? Heck of a good bunch questions, that. FWIW, I once enquired about a seat at the USB table. But $25k a year was not in my budget. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Serial FPGA buses/interconnections [Was: Sandy box]
CANopen might be what you are searching for. On June 6, 2015 10:19:45 PM CEST, Philipp Burch p...@hb9etc.ch wrote: Hi everyone, when we're talking about buses and interfaces, I'd like to bring up another topic concerning me recently: We're building some kind of PLC and motion controller mainly for internal uses, which is built around FPGAs. Our FPGA configs are crafted specifically for what the devices need to do, so there is no softcore or other microcontroller around. We now have a simple serial interface connecting multiple boards using differential pairs (RS-485-like) for RX and TX, transmitting frames of some 64 bits each. This works, but is obviously completely proprietary. Hence the question: Are there standard interfaces (call them buses if you like, I don't mind) of similar complexity with open specifications around? I personally like the idea of the summation frame method (Summenrahmenverfahren in German) as is used by EtherCAT, but this interface is overkill for us and also not open unless you are some kind of member. I found Interbus which seems to fit quite ideally, but, again, is not as open as I'd like it to be and it also looks to be kind of obsolete. Rough requirements would be: - Usable for daisy-chaining (no common bus) - Data rate somewhere in the range 1Mbps .. 10Mbps - Serial with exactly one RX and one TX pair in each link - Suitable for deterministic cyclic transfers with some tens of bytes each Any ideas, hints, comments? Regards, Philipp -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Sandy box
I recommend you some literature on this topic. Embedded real-time systems are not data centers. Hermann Kopetz, Real-Time Systems: Design Principles for Distributed Embedded Applications, Springer, 2011, ISBN: 978-1-4419-8236-0 Roman Obermaisser, Event-Triggered and Time-Triggered Control Paradigms, Springer, 2005, ISBN: 0-387-23043-2 There is an Raspberri Pi model with PCB edge connector: https://www.raspberrypi.org/raspberry-pi-compute-module-new-product/ But I don't get it. What makes this type of connector better than a pin header? If one wants to connect sensors to this device it would be necessary to create a break-out board anyway. Rafael writes: Perhaps it's just semantics but we are not making progress here ;-) On 06/06/2015 05:46 AM, Alexander Rössler wrote: Rafael writes: On 06/05/2015 01:18 AM, Alexander Rössler wrote: Rafael writes: On 06/04/2015 07:13 AM, Ron Bean wrote: If you need one computer to see the GUI and one for realtime effects, why not just start out with a real computer and load Linux and LinuxCNC on it? snip In my HW support experience I came across PDP-11 systems running in steel mills, nuclear and hydro power plants, factories, etc. with little or no graphics. Most used VT100, some used more advanced color terminals. Systems with 32kW(ord) or 64kW RAM controlled huge machinery with RTOS on much slower CPU than we have today. The future are distributed systems. Distributed setups are industrial standard and are used everywhere from automotive to automation industry. CAN and Ethernet are used these days to distribute neither one is suitable for strict real time. CAN as event triggered bus is not. You may understand TCP/IP as Huh??? BUS is not event triggered? Every bus I know has an interrupt line(s). Generic BUS is just a data path, not an interface, you are mixing the two. Ethernet. However, Ethernet can be used as time-triggered bus too. There are many standards such as EtherCAT and Powerlink which are widely used in automation industry. But that is not a data bus I'm talking about! Using your definition, RS232, parallel port (see, we call it a port), phone line, and traditional CaTV network are also a bus. In my understanding BUS is physical component of a computer to connect numerous peripherals to the CPU and among themselves. DMA for example is used for data transfer between the peripheral and storage (RAM, disk drive, SSD) without CPU intervention. No such thing in ethernet. All these concepts were resolved on mainframes decades ago. What changed is the size of components and their speed. functionality across different ECUs. The BBB is fine when it comes to CAN but an even stronger platform from TI is coming up: the BeagleBoard X15 with Gigabit Ethernet support Don't mix computer BUS and cabling. Two different things. Some cables do act as traditional extend bus but none at the length of an airplane or HMMVE. What good is Gigabit Ethernet when you need to connect a keypad, a switch, accelerometer, or optical sensor to BBB? Ethernet is not a bus, it's one of communications peripherals. You are wrong, Ethernet is a bus. When you take a look at the history This is becoming silly. Ethernet IS NOT A computer BUS just like USB, RS232, RS485, 60mA current loop, are not traditional data buses. Perhaps the terminology got confused when USB was introduced and you know how much of a bus that is or how real time that can be. I work in large data centers and never hear anybody calling ethernet a bus. In some instances we use Cat-6 cables, in other we use optical for 10Gb or 40Gb connections between the routers, switches and servers. I would never call that cheap. A single ethernet interface costs more than a large box of BBBs. you will see that it started out with a very different physical interface as nowadays. The huge advantage of Ethernet is that network I know very well how it started and what kind of connectors were used to connect ethernet interfaces on DEC or other computers over the years. At some point coax cable was used to string PCs together into a network. I probably still have RG-58 cables around, good for amateur radio. If you forgot 50 ohm terminator, or used a cheap BNC connector, that connection went wireless and transmitted all over the spectrum except between the computers. I paid my share to that hell but we ever called it an ethernet BUS! hardware is cheap (not all is RT compatible though) because it acts only on the data-link layer (Ethernet frames). What I am talking about are Ethernet hubs. I hear hardware is cheap all the time. It is in some instances but when I ask an engineer that demands additional disk space because he thinks hardware is cheap: if it's cheap, why don't you go out and buy a disk drive? they walk away and start cleaning their home directories full of junk on servers because management tells them to do so
Re: [Emc-users] Sandy box
Rafael writes: On 06/05/2015 01:18 AM, Alexander Rössler wrote: Rafael writes: On 06/04/2015 07:13 AM, Ron Bean wrote: If you need one computer to see the GUI and one for realtime effects, why not just start out with a real computer and load Linux and LinuxCNC on it? snip In my HW support experience I came across PDP-11 systems running in steel mills, nuclear and hydro power plants, factories, etc. with little or no graphics. Most used VT100, some used more advanced color terminals. Systems with 32kW(ord) or 64kW RAM controlled huge machinery with RTOS on much slower CPU than we have today. The future are distributed systems. Distributed setups are industrial standard and are used everywhere from automotive to automation industry. CAN and Ethernet are used these days to distribute neither one is suitable for strict real time. CAN as event triggered bus is not. You may understand TCP/IP as Ethernet. However, Ethernet can be used as time-triggered bus too. There are many standards such as EtherCAT and Powerlink which are widely used in automation industry. functionality across different ECUs. The BBB is fine when it comes to CAN but an even stronger platform from TI is coming up: the BeagleBoard X15 with Gigabit Ethernet support Don't mix computer BUS and cabling. Two different things. Some cables do act as traditional extend bus but none at the length of an airplane or HMMVE. What good is Gigabit Ethernet when you need to connect a keypad, a switch, accelerometer, or optical sensor to BBB? Ethernet is not a bus, it's one of communications peripherals. You are wrong, Ethernet is a bus. When you take a look at the history you will see that it started out with a very different physical interface as nowadays. The huge advantage of Ethernet is that network hardware is cheap (not all is RT compatible though) because it acts only on the data-link layer (Ethernet frames). What I am talking about are Ethernet hubs. The idea of time-triggered buses is to resend that every cycle. Therefore, a higher network bandwidth means that one can use a smaller cycle time. The bandwidth is not wasted as some people stated. Why not attaching the sensors you mentioned directly to the BBB? Just create (or use one of the many) capes with a decent connector and you are fine. If you want to go the industrial standard way you can buy sensors with bus interface (I am not talking about I2C, SPI, ...). Onewire is common for simple sensors. Another example in the automotive industry it is pretty common to have ECUs that do only simple tasks like reading out sensors and providing the data on a CAN bus. With microprocessors getting cheaper and cheaper the industry will further move into distributed systems. On the other edge of the spectrum we have another low cost solution that is currently funded on kickstarter C.H.I.P. a 9$ dollar Linux computer with Bluetooth and WLAN = a cheap solution to connect sensors. This is one of a kind toys that don't make a standard! Nor would anybody serious use it for a CNC machine. I even heard about things like fly-by-wireless. Which boils down to removing the wired buses inside a plane. So face the facts: Big monolithic computer setups will soon be banned to server farms. Most airplanes and modern military vehicles use computers based on decades of developments on VME bus and it's derivatives because they need a lot of connections. That likely includes CompactPCI, it's emerging CompactPCI Serial, and VPX. As tiny lasers are getting cheaper, cost of building optical bus and compatible peripherals will become more common in the near future so we'll see even more data buses. Optical cables have different problems than metal cables. They have more problems when it comes to mechanical stress. I am not sure they will succeed copper wires that quickly. When you take a look inside an airplane you will see that the wiring is consuming a lot of space inside the hull. The idea of replacing some buses with wireless interfaces drastically reduces development costs. So maybe in 30-50 years we will have wireless operating planes. Every computer in existence has a bus, available or not, for connections to additional peripherals. There is a bus on BBB, RaspberryPi, Radxa, and other little SBCs to add peripherals. My comment was about the problem with every little SBC having different connectors and their positions on the board while all are using sandwich mechanical architecture that cannot be expanded easily. What you are pointing out is that these devices do not come with standard connectors. There are some capes (additional board that can be put on the pin headers) that provide different connectors for different applications. The BeagleBone Green will come with connectors for the Groove sensors if you want something out of the box. Furthermore, you have USB and Ethernet connectors available. However, I agree that connectors
Re: [Emc-users] Sandy box
No, USB does not work for tablets. At least not for Android tablets. This would require root access. However, the next generation Android with the automotive interface will probably make this possible even without root access. When you plug the USB cable into a computer it will attach itself as mass storage device. On the flash memory all the configurations and applications are located (for Windows, Linux and Mac). Furthermore, an additional Network interface will appear (RNDIS driver). This makes it possible to attach the box to any computer without installing anything! The reason is users complained about LinuxCNC being hard to install (mainly because you need a Linux capable computer). With this solution they can use wathever OS they prefer. Some reported it even working on Windows Surface tablets. An additional aspect of the box is that it is extremely portable. When you take a look at the UNIMAT machines you see why this a huge plus. They are very small and portable. Since it runs also without GUI (detachable) you can even work with more than one machine similutaniously. With the remote launcher you can even start different configurations from a tablet, no computer necessary. On June 5, 2015 9:36:07 PM CEST, Przemek Klosowski przemek.klosow...@gmail.com wrote: On Fri, Jun 5, 2015 at 3:21 PM, Mark Wendt wendt.m...@gmail.com wrote: Then what exactly is the USB cable being used for? Connect a USB cable between the tablet and the BBB, and have them talk to each other by network transport over USB, including doing remote X protocol to the server on the tablet. I described that couple of weeks ago in this list. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Network Broadcast?
One of the few reliable solutions to broadcast a message over the network without concern about the operating system is either using a simple and stupid UDP package (however UDP broadcasts are blocked in many networks) or registering a MDNS service. Basically what you need is some Python code. Another option that may work. Use some kind of instant messaging client that supports dbus on Linux. Create a script that sends a message to a person (or listening machine) using the dbus interface. On the clients use whatever IM client you want. Regards Alexander On Thursday 05 February 2015 16:08:52 andy pugh wrote: Have I already asked this? It would be really nice if an M-code could send a network broadcast to all the machines on my local network (Mac, PC, Linux) to tell me that a machine needs attention. (At the moment that attention is unclamping the A-axis so that it can re-position the part) Any ideas? -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] What was the name of that board?
On Friday 09 January 2015 05:58:14 Sven Wesley wrote: 2015-01-08 23:47 GMT+01:00 Sven Wesley svenne.d...@gmail.com: Thanks Viesturs but that's not the one. There is another one complete with display and everything that is fully compliant with our G-code. Gotta find it... Found it! In the mail thread with the subject I'm going to build something small, need a cheap stepper driver, answer by Kerry Lynn. It's the TinyG setup I was looking for. https://www.synthetos.com/what-is-tinyg-and-why/ https://www.youtube.com/watch?v=Ym3K71dbbVw This was some time ago it seems. You could also use one of the Machinekit supported boards and get the full Machinekit/LinuxCNC experience: http://blog.machinekit.io/p/hardware-capes.html Grbl is the Arduino approach for CNC control. Not very interesting in my opinion since everything is going into the SoC direction. _ Alexander -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Persistently storing HAL pin value
On Wednesday 24 December 2014 09:20:05 schoone...@btinternet.com wrote: Hi Alex Seb wrote: If you're making a userspace component (as opposed to a realtime component), you can just use fopen/fwrite/fclose to persist the values when they change, and fopen/fread/fclose at startup to restore them. My component was called paramsaver, that is what it did, except that it created pins to match the data types, which could be linked to pyVCP widgets or whatever and it both saved and initialised values through the linked pins You can find it at mgwareDOTcoDOTuk HAL Components Paramsaver That was exactly what I was looking for. Thank you very much. Regards Alexander -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Persistently storing HAL pin value
On Monday 22 December 2014 11:05:38 Gene Heskett wrote: On Monday 22 December 2014 08:57:19 Alexander Rössler did opine And Gene did reply: Is there a way to store HAL pin values persistently across LinuxCNC sessions? Regards Alexander I haven't tested to see if it still works, but 3 or 4 years ago I noted that my variables were still set from a previous run, and even survived a reboot!, and were also available after a different gcode file had been loaded and executed. I think this applies for the protected system variables. Can you remember what variables you used? -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Persistently storing HAL pin value
On Monday 22 December 2014 18:01:06 Marius Liebenberg wrote: If it is widget pins then yes Arceye created a way to store values. I dont recall the actual solution but if you search the forum I am sure that you will find it. That's not exactly the solution I am looking for as it would require a common user interface. You could also route them trough a python script and make use of the persistence functions or even write them to a file if any change is detected. Good idea. Something like a proxy HAL component that stores and loads the output pin values comes to my mind. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Persistently storing HAL pin value
Is there a way to store HAL pin values persistently across LinuxCNC sessions? Regards Alexander -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] single board computer
On Sunday 23 November 2014 20:24:26 Ralph Stirling wrote: It is very likely that your friends were showing you a BeagleBone or BeagleBoneBlack sbc, which uses a TI processor, running some version of Linux. The ARM processors used on these inexpensive boards are very good for low-power, low-cost applications, but still lag behind the performance possible with the larger x86 or amd64 motherboards. Reliability of fanless, solid-state disk computers should be excellent, regardless of whether they use ARM or traditional processors. -- Ralph It really depends on your application. If you want to control a 10.000$ CNC mill then the price of the fan-less computer is comparable low and you are probably better with such a system. For a small 500-1000$ CNC machine a SoC might be better because of the price and size of device. Regards Alexander -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] 3D Software for Linux
2014-07-30 22:35 GMT+02:00 Bruce Layne linux...@thinkingdevices.com: I installed Inkscape, which apparently has some of the artistic features in the software that was promoted via spam. Inkscape is a vector graphics program, sort of the open source version of CorelDraw. I haven't used Inkscape yet, because I'm not an animator or artist, but I installed it in the hope that I could import raster art (GIF, JPG, etc.) and output G code that I could eventually use to control the 80 watt laser that I'm *still* trying to make time to build. LinuxCNC will control the laser, of course, but it's not good at raster engraving. It'll sort of do it, but it's my impression that it's a bit of a double clutch and fuss at it operation. I was hoping I could just tell Inkscape to generate G code, and tell it to start on the perimeter of each graphic element and spiral inward with a certain stepover (the laser beam width). That would also be potentially useful for machining logos using a CNC milling machine. There's a G-code extension so Inkscape can output vector graphics as G-code. Imho Inkscape is one of the best open-source graphic tools available. I use it for years now to create logos and icons for my applications and from time to time to create some more artistic stuff. If you want to create some flat 3D models you can combine it with OpenSCAD http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/DXF_Extrusion -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] BeagleBone Configurations
I have created a component for led-dimming: https://github.com/strahlex/TCT3D/blob/master/comp/led_dim.comp Would be nice to have it in Machinekit for some demo projects. Am Dienstag, 15. April 2014 17:07:09 UTC+2 schrieb Charles Steinkuehler: I am getting close to having the next major version of the BeagleBone uSD card image ready. I have some pending configurations to add (for my CRAMPS board and the Xylotex BBB_DB25), and am working on removing the absolute paths. If there are any new boards, standard machine configurations, or other changes you'd like to see included in the new images, please let me know. -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Touchy with 1024x600 resolution display?
Hi, I am currently working on some new QML based GUI especially designed for small touchscreen displays to control 3D printers. That kind of thing might be also suitable for your screen as QML is very flexible. Regards Alexander On Tuesday 29 October 2013 19:39:03 Thomas Kaiser wrote: On 10/29/2013 01:33 AM, andy pugh wrote: On 28 October 2013 22:59, Thomas Kaiser c...@kaiser-linux.li wrote: Touchy is too big for this screen! (LinuxCNC 2.5.3 on Ubuntu 10.04.4 LTS) IIRC the trick is to fiddle with the font DPI until the width works System-Preferences-Appearance-Fonts-Details-Reolution Then in Touchy play with the font sizes to fit. http://imagebin.org/275087 Is 1080 x 595 (as I got bored of adjusting the VM screen size) Hello Andy Thank you for this tip. I could manage to get Touchy fit to the screen. But, I think this is not the correct methode to get Touchy fit to the screens resolution. Anyway, thanks again. Thomas -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg. clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
