I read and it mostly seems to be about security. Realtime scheduling make sense for every task which is periodic or may be treated as a periodic task. A really good example is a serial receive buffer since data will be lost if not handled periodically.
GUI I usually treat as periodic task with a dead time of about 20-50 milliseconds even though it seldoms happens. Video I guess is about 30-50 milliseconds. Servo loop is around 1 milliseconds and even though little computational power is required ordinary computer seems to have problem with this. They mention something about support for a real time operating system and for linuxcnc the kernel RT patch is used or RTAI. On a micro controller I most often use an interrupt with suitable priority, software is most often simple with only a few well known interrupts so most often it works really well. The most useful scheduling schemes are Earliest Dead Line first https://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling and for static priority rate monotonic which may be implemented with nested interrupts with priority https://sv.wikipedia.org/wiki/Rate-monoton_schemal%C3%A4ggning Dead line should be equal to periodic which most often is possible. For video with a dubble buffer, for serial receive buffer interrupt is triggered then buffer is half full, ... It is commmon to talk about jitter which make som sense but for properly implented EDF or rate monotonic scheduling jitter within period make no difference. Here http://linuxcnc.org/docs/2.6/html/code/Code_Notes.html at "4. Architecture overview" is probably what you need to understand how the different parts of linuxcnc is put together. The real time part I want to put on simple computer and the GUI on an ordinary computer since they are readily available cheap. There are two advantages: I want to keep real time communication local and remove real time demand from ordinary computer. Regards Nicklas Karlsson On Sun, 11 Jun 2017 23:19:27 +0200 theman whosoldtheworld <bleachk...@gmail.com> wrote: > see these: > https://blog.qt.io/blog/2017/05/17/integrity-rtos-support-qt-5-9-lts/ ... > As you said, me too I try is little bit hard use qt c++ program instead > Lcnc c/c++ for driving servos machines .... but it promise rtos realtime so > sometings is for certain possible ... any how the goal for new qt5.9 rt is > automotive industries ... not robotics or chips machines ...the common > denominator is sending realtime command signals and receiving them, a > little logical work to make the signal available and allow the operator to > see or send these signals. Taking the sums I think is the first test to > pave the way for the qt to the future automatic driving machines. > > my intention is use qt5.9 to interface a gui using a modern opensource > industrial bus, with other electronics devices and some pc with Lcnc > without gui.I'm not going to use the industrial buses to drive the servo > ... I find it safer to use the command and safety buses (even in the servo) > and use traditional piloting for the positioning and the feedbak ... so two > different line to the servo on two totally different channels, analogue for > driving, digital for safety and functional. It's like having two dogs who > are guarding one against each other. > > The project would be: to create an rt component that starts as if it were a > gui at opening lcnc, the component starts a server connection of some > industrial bus and waits for queries from slaves or slaves, as for example > some commands / requests may arrive From a plc of security; Create a gui in > qt on remote pc having its main thread, secondary ones of service and then > one or more thread rt for communication to pc lcnc via industrial bus rt or > other devices (eg plc security). > > I've already relayed this thing with modbus as a test ... but modbus, even > turning very fast with new technologies, even over 115000, always sends 16 > bits at a time ... for good remote control Of Lcnc serve at least 48 bits > for the on / off commands + others to have floats .... so a fast and large > bus is what you need ... believe that's why Sebastian has used QUIC. > > I'm happy to chat with you about this. > > bkt > > > 2017-06-11 17:21 GMT+02:00 Nicklas Karlsson <nicklas.karlsso...@gmail.com>: > > > On Sat, 10 Jun 2017 22:48:47 +0200 > > theman whosoldtheworld <bleachk...@gmail.com> wrote: > > > > > ... thanks for your advice ... but there are 3-4 solution for these > > things > > > .... > > > But at present I am more concerned with understanding the use of various > > > Lcnc files than any other. > > > > The lcnc files are a little bit hard to understand. The *.hal files are > > almost like netlists used for schematics. It make a lot more sense to > > visualize the configuration in schematic. > > > > There are some old almost working example with geda gschem, whenever I > > have a few I will try to get the script to work. I also heard something > > about rockhopper, it is also vizualized graphically although this was some > > kind of web based interface, html have limitations then it come to user > > interfaces and usually have a second or so delay whenever something is > > pressed. Graphical representation with gschem should be simple, script is > > currently in python while most other output from gschem via gnetlist is in > > scheme language. > > > > > > I am fully with you then it come to split application in non real time GUI > > and real time. And at least partly with you then it come C++ and do not > > like python programming language but use whatever is available or have been > > used before. > > > > > > Then it come to GUI I like the glade interface designer and automatic > > connection of callback functions. Automatic connection of callback > > functions are available in C but not C++ and for python I do not know. > > > > ------------------------------------------------------------ > > ------------------ > > 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 ------------------------------------------------------------------------------ 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
