QtQuickVcp, Machineface and Cetus

3388 views
Skip to first unread message

Alexander Rössler

unread,
Nov 17, 2014, 4:53:56 PM11/17/14
to <machinekit@googlegroups.com>
I am very happy to announce that I can finally present the first two
QtQuickVcp based user interfaces.

Machineface: https://github.com/strahlex/Machineface
and
Cetus: https://github.com/strahlex/Cetus

Machineface is especially designed to work on small screens (7 inch tablets)
to control 3D printers.

Cetus is something similar to Axis, but also works nicely on 10 inch tablets.

I have described instructions for testing here:
https://github.com/strahlex/QtQuickVcp/wiki/Testing-mkwrapper

The "Machinekit-Client" is available as binary distribution for Linux,
Windows, Mac and Android. It also works on iOS, but I have no idea how to
deploy besides the Apple App Store (which I will do some time in the future).

You do not need anything besides a text editor to modify the user interfaces
so feel free to modify and improve them. However, a QtQuickVcp development
environment might be useful if you want to create your own (which is very
easy).

My video recorder (a.k.a. my smartphone) is not willing to work today so I can
not make a video yet.

Please test, contribute and discuss.

Regards
Alexander

Charles Steinkuehler

unread,
Nov 17, 2014, 5:11:56 PM11/17/14
to Alexander Rössler, <machinekit@googlegroups.com>
On 11/17/2014 3:53 PM, Alexander Rössler wrote:
> I am very happy to announce that I can finally present the first two
> QtQuickVcp based user interfaces.
>
> Machineface: https://github.com/strahlex/Machineface
> and
> Cetus: https://github.com/strahlex/Cetus
>
> Machineface is especially designed to work on small screens (7 inch tablets)
> to control 3D printers.
>
> Cetus is something similar to Axis, but also works nicely on 10 inch tablets.

*VERY* Exciting Alex!

They both look great, especially for a first version!

Now to see if I can get one of them running...is any Android platform OK
for testing, or do I need a specific version?

If the BBB switches to the lxqt based desktop, will these run native on
the BeagleBone (possibly even with acceleration, if the Qt stack
supports it)?

--
Charles Steinkuehler
cha...@steinkuehler.net

signature.asc

Bas de Bruijn

unread,
Nov 18, 2014, 1:43:08 AM11/18/14
to Alexander Rössler, machi...@googlegroups.com
Can’t wait to try it!
thanks for all the work Alex!
Regards,
Bas
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.

Alexander Rössler

unread,
Nov 18, 2014, 3:28:58 AM11/18/14
to Charles Steinkuehler, <machinekit@googlegroups.com>
Yes it should work on any Android newer than 2.3. I tested on a 4.4, I am not sure about 5.0 since they have changed something with the application environment. I tested it with a Nexus 7 and a Nexus 10, I also tried it on Nexus 4.

Regards
Alexander
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Alexander Rössler

unread,
Nov 18, 2014, 3:32:41 AM11/18/14
to Charles Steinkuehler, <machinekit@googlegroups.com>
And yes it will also work on the BBB itself with a recent version of Qt available (5.2 or newer). If LXQt runs on it it should be fine. However, I was not able to get the early LxQt BBB images running on my BBB. So it may take some time until we see embedded user interfaces.

Regards
Alexander

On November 17, 2014 11:11:54 PM CET, Charles Steinkuehler <cha...@steinkuehler.net> wrote:

--

Charles Steinkuehler

unread,
Nov 18, 2014, 6:58:32 AM11/18/14
to Alexander Rössler, <machinekit@googlegroups.com>
On 11/18/2014 2:32 AM, Alexander Rössler wrote:
> And yes it will also work on the BBB itself with a recent version of
> Qt available (5.2 or newer). If LXQt runs on it it should be fine.
> However, I was not able to get the early LxQt BBB images running on
> my BBB. So it may take some time until we see embedded user
> interfaces.

The Jessie images for the BBB use lxqt and the 3.14 kernel that should
provide hot-plug USB and working GPU acceleration. Now someone needs to
try making a Xenomai kernel with the SGX drivers enabled and see if it
all works together.

--
Charles Steinkuehler
cha...@steinkuehler.net

signature.asc

Alexander Rössler

unread,
Nov 18, 2014, 7:21:06 AM11/18/14
to Charles Steinkuehler, <machinekit@googlegroups.com>
On Tuesday 18 November 2014 05:58:29 Charles Steinkuehler wrote:
> The Jessie images for the BBB use lxqt and the 3.14 kernel that should
> provide hot-plug USB and working GPU acceleration. Now someone needs to
> try making a Xenomai kernel with the SGX drivers enabled and see if it
> all works together.
Also to mention is the fact that this might make USB hot-plug working.

Dear Santa...

Dave Cole

unread,
Nov 18, 2014, 9:50:54 AM11/18/14
to machi...@googlegroups.com
VERY impressive.  

Will try it out... 

Thanks!

Dave
Sent from my Android device with K-9 Mail. Please excuse my brevity. --
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at http://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.



This email is free from viruses and malware because avast! Antivirus protection is active.


Pruska Modr

unread,
Nov 18, 2014, 6:59:35 PM11/18/14
to machi...@googlegroups.com
Hi,
not bad, not bad at all. I am going to try it next time I have free time. Keep it up.


I have a questing - I do not know if it is more to the display interface or communication protocol ( Am I correct that it is called Machinetalk?) but what happens when connection is lost during run? For example I have device connected to home network which consists of several APs. As I do not have zero lost automatic handoff, there could be about second or two between reconnecting when roaming with tablet (or phone, basically mobile device).

And depending how this is implemented, can I set up my own rule how the system will react to such occurence?

Tjanks for answering,
PM

Dne pondělí, 17. listopadu 2014 22:53:56 UTC+1 Alexander Rössler napsal(a):

Phill Carter

unread,
Nov 19, 2014, 4:01:33 AM11/19/14
to machi...@googlegroups.com
I am having trouble getting this working on my BBB.
I was able to follow the instructions at:
http://www.machinekit.io/docs/packages-debian/
and:
https://github.com/strahlex/asciidoc-sandbox/wiki/Creating-a-Machinekit-Debian-Image
to successfully install and run machinekit on a BBB via the SD card.
I then followed the instructions at:
https://github.com/strahlex/QtQuickVcp/wiki/Testing-mkwrapper
except I didn't apt-get upgrade as I wasn't 100% sure of the correctness my sources.list file.
After running lathe.py on the BBB, then running run.sh on the client (Debian Wheezy) machinekit appears, I can select the instance of machinekit that is running then select Cetis but Cetis just sits there saying 'Waiting for services to appear', none of the four listed services are active and Cetis is empty except for some menus at the top and a status bar at the bottom.
Relevant files are available at:
https://www.dropbox.com/sh/q0kmxkhdi1k8fas/AAAvjSVi4f7yKOx_BX5swtUIa?dl=0
Cheers, Phill

schoo...@btinternet.com

unread,
Nov 20, 2014, 9:45:03 AM11/20/14
to machi...@googlegroups.com
Hi Alex,

I have been trying this without success, partly hampered by the
instructions being based upon package installation I think.

I have machinekit built as a RIP on Wheezy running the debian rt-preempt
kernel

I have Qt5.3 installed, build environment set up and your QtVcp repo
built and installed, so all the plugins and libs etc are present.

Cetus builds from the repo and it runs

I have the MACHINEKIT.INI exported and it contains the UUID, REMOTE = 1
and INTERFACE = lo to use localhost 127.0.0.0

The hal file contains loadusr -W haltalk

Whether I start an instance of machinekit using axis or mkwrapper, cetus
just sits there looking for available instances

It has been a long time since I tried the halremote examples, probably
missing something but it is not obvious.

regards

Mick


Alexander Rössler

unread,
Nov 20, 2014, 9:56:03 AM11/20/14
to machi...@googlegroups.com
Sounds like you haven't started a configserver. Even if you run the user
interfaces locally you need the configserver as entry point. (ServiceDiscovery
is looking for it). Just run configserver without any arguments. Please also
try the AppDiscover client (QtQuickVcp/applications/AppDiscover/) if there are
instances running you can use the Service Monitor from the local applications
to see what service are running.

Regards
Alexander

schoo...@btinternet.com

unread,
Nov 20, 2014, 10:29:21 AM11/20/14
to machi...@googlegroups.com
Hi

Made progress just before your reply, problem with the configserver path

Will discover Machinekit at 127.0.0.1 and with the mkwrapper loaded as
display
will then discover services and show Cetus screen

Well done, now have to run some tests through it to test it all, but
that's another day

Proof of life attached

regards



Selection_005.png

Alexander Rössler

unread,
Nov 20, 2014, 11:07:06 AM11/20/14
to machi...@googlegroups.com
On Wednesday 19 November 2014 01:01:33 Phill Carter wrote:
> I am having trouble getting this working on my BBB.
> I was able to follow the instructions at:
> http://www.machinekit.io/docs/packages-debian/
> and:
> https://github.com/strahlex/asciidoc-sandbox/wiki/Creating-a-Machinekit-Debi
> an-Image to successfully install and run machinekit on a BBB via the SD
It looks like mkwrapper was not started for some reason. Can you please try to
remove the commented DISPLAY variables from the ini file.
If that does not work start linuxcnc with an existing UI and run mkrapper
manually:
mkwrapper -d --ini <ini>
it should give you some debug output and maybe some hints whats going wrong.

Regards
Alexander

John Morris

unread,
Nov 20, 2014, 9:23:14 PM11/20/14
to machi...@googlegroups.com
That's just gorgeous. I hope everyone realizes just how enormous a step
forward this is for Machinekit.

I wonder how many SLOC in the Cetus and Machineface apps, not including
libraries?

John

Phill Carter

unread,
Nov 20, 2014, 11:54:33 PM11/20/14
to machi...@googlegroups.com

Alexander,
Thanks for replying.
Removing the commented DISPLAY variable made no difference.
The first run with mkwrapper loaded manually gave me an error that the folder for PROGRAM_PREFIX didn't exist, which it didn't as I had forgotten to copy it across... After creating the folder and running mkwrapper manually again - Cetus almost loads fully, the top icon bar has no icons and the File and Machine menus are empty. If I press F1 it goes out of e-stop, the DRO fully populates then after abut 10 seconds it goes back inti e-stop.
I rebooted and tried to run it automatically but it still has exactly the same symptoms as before.
New files are at  https://www.dropbox.com/sh/q0kmxkhdi1k8fas/AAAvjSVi4f7yKOx_BX5swtUIa?dl=0  again and begin with 4.
Cheers, Phill

 

Alexander Rössler

unread,
Nov 21, 2014, 2:38:17 AM11/21/14
to machi...@googlegroups.com
> Alexander,
> Thanks for replying.
> Removing the commented DISPLAY variable made no difference.
> The first run with mkwrapper loaded manually gave me an error that the
> folder for PROGRAM_PREFIX didn't exist, which it didn't as I had forgotten
> to copy it across... After creating the folder and running mkwrapper
> manually again - Cetus almost loads fully, the top icon bar has no icons
> and the File and Machine menus are empty. If I press F1 it goes out of
> e-stop, the DRO fully populates then after abut 10 seconds it goes back
> inti e-stop.
> I rebooted and tried to run it automatically but it still has exactly the
> same symptoms as before.
> New files are at
> https://www.dropbox.com/sh/q0kmxkhdi1k8fas/AAAvjSVi4f7yKOx_BX5swtUIa?dl=0
> again and begin with 4.
> Cheers, Phill
File and Machine menu are not implemented yet so this is normal. The missing
icons are unusual.Can you try pull the Cetus source code again. Also please
build QtQuickVcp in debug mode so it will it will be easier for me to resolve
your problems.

Something goes wrong with the loopback interface. You are probably resolving
the services using MDNS can you try switching to Unicast.
(in the Cetus main.qml add "lookupMode: ServiceDiscovery.UnicastDNS" to the
ConnectionWindow.

Regards
Alexander

Alexander Rössler

unread,
Nov 21, 2014, 4:32:51 AM11/21/14
to machi...@googlegroups.com
> I have a questing - I do not know if it is more to the display interface or
> communication protocol ( Am I correct that it is called Machinetalk?) but
> what happens when connection is lost during run? For example I have device
> connected to home network which consists of several APs. As I do not have
> zero lost automatic handoff, there could be about second or two between
> reconnecting when roaming with tablet (or phone, basically mobile device).
It is mostly handled by ZeroMQ. However, as a timeout is not detectable by the
application using ZeroMQ we have introduced heartbeat messages from client to
server in case of ROUTER-DEALER pattern and server to client in case of PUB-
SUB pattern. So the applications knows when a timeout happens. This is
indicated with grayed-out elements or "busy" indicators in the user interface.
Reconnect happens automatically. It works very well for me with a weak wifi
signal.

> And depending how this is implemented, can I set up my own rule how the
> system will react to such occurence?
At the moment it is not possible. However, we thought about it already. One
solution would we to handle disconnects on the HAL level (e.g. to trigger
ESTOP). There is a discussion about that topic somewhere on GitHub in the
issues.

Regards
Alexander

Phill Carter

unread,
Nov 21, 2014, 4:40:59 AM11/21/14
to machi...@googlegroups.com

Downloading Cetus again fixed the icon problem.
Switching to unicast made no difference.
I will get to  the QtQuickVcp build sometime over the weekend.
Thanks again, it looks awesome...
Cheers, Phill

schoo...@btinternet.com

unread,
Nov 22, 2014, 1:58:04 AM11/22/14
to machi...@googlegroups.com

Hi Alex

Just a couple of initial reports on testing. Both relate to the gcode
browser.

1) If there is an error in the gcode, upon initial load, the error is
reported as being on line '-2'

2) The gcode highlighting is consistently running 1 line ahead of the
actual execution line.

I remember having huge problems with this latter issue when I started
writing a Qt GUI to linuxcnc.

emcStatus->task.currentLine
emcStatus->task.motionLine
emcStatus->task.readLine
all returned different line numbers, but often none of them were correct.

If your highlighting remains consistently one line ahead, you have
cracked that problem and just need to adjust back by one

I have not had the time to dig into your widgets to see the underlying
code regards 1)
The initial error will come from the interpreter, but unsure what
formatting takes place before display
I will report back if I trace what is causing it

Otherwise looking good so far

regards



Alexander Rössler

unread,
Nov 22, 2014, 2:38:35 AM11/22/14
to machi...@googlegroups.com
Re: [Machinekit] Re: QtQuickVcp, Machineface and Cetus
From: Alexander Rössler <mail.ar...@gmail.com>
To: "schoo...@btinternet.com" <schoo...@btinternet.com>
Date: Yesterday 22:11:44
> 1) If there is an error in the gcode, upon initial load, the error is
> reported as being on line '-2'
>
> 2) The gcode highlighting is consistently running 1 line ahead of the
> actual execution line.
>
> I remember having huge problems with this latter issue when I started
> writing a Qt GUI to linuxcnc.
>
> emcStatus->task.currentLine
> emcStatus->task.motionLine
> emcStatus->task.readLine
> all returned different line numbers, but often none of them were correct.
>
> If your highlighting remains consistently one line ahead, you have
> cracked that problem and just need to adjust back by one
I will take a look at this. All the magic happens here:
https://github.com/strahlex/QtQuickVcp/blob/master/src/pathview/GCodeSync.qml#L43

> I have not had the time to dig into your widgets to see the underlying
> code regards 1)
> The initial error will come from the interpreter, but unsure what
> formatting takes place before display
> I will report back if I trace what is causing it
Take a look at:
https://github.com/machinekit/machinekit/blob/master/src/machinetalk/mkwrapper/mkwrapper.py#L210
The preview interpreter is generating the error message. The preview
interpreter in general is not very polished yet.

Thank you for testing.

Regards
Alexander

schoo...@btinternet.com

unread,
Nov 22, 2014, 11:46:00 AM11/22/14
to machi...@googlegroups.com


2) The gcode highlighting is consistently running 1 line ahead of the
actual execution line.

I remember having huge problems with this latter issue when I started
writing a Qt GUI to linuxcnc.

emcStatus->task.currentLine
emcStatus->task.motionLine
emcStatus->task.readLine
all returned different line numbers, but often none of them were correct.

If your highlighting remains consistently one line ahead, you have
cracked that problem and just need to adjust back by one

> I will take a look at this. All the magic happens here:
> https://github.com/strahlex/QtQuickVcp/blob/master/src/pathview/GCodeSync.qml#L43
>
>
PR submitted, removing the line number increment in

GCodeSync.qml

var currentLine = status.motion.motionLine + 1

seems to leave the highlight in the correct line for the current motion.


regards

Alexander Rössler

unread,
Nov 22, 2014, 12:30:12 PM11/22/14
to machi...@googlegroups.com
Thank you, merged.

Regards
Alexander

Bas de Bruijn

unread,
Nov 23, 2014, 11:12:54 AM11/23/14
to Alexander Rössler, machi...@googlegroups.com
Hi Alexander,
Today I wanted to give your project a try, I downloaded your installation script and ran it.
I finally got the message "Enable Qbs and BBIOConfig plugins in Qt Creator and set up Machinekit target" but I have no idea what I should do next.
Thanks,
Bas

Alexander Rössler

unread,
Nov 23, 2014, 11:32:23 AM11/23/14
to machi...@googlegroups.com
The message means you should enable these plugins in Qt Creator if you want to
use the Machinekit SDK. It is not necessary for QtQuickVcp.

Just open Qt Creator open the QtQuickVcp.pro with it. And follow this wiki
entry here: https://github.com/strahlex/QtQuickVcp/wiki/QtQuick-Virtual-Control-Panel#qtquickvcp

After that open the AppDiscover.pro in applications/AppDiscover and build/run
it. For the rest follow the Testing mkwrapper wiki page
https://github.com/strahlex/QtQuickVcp/wiki/Testing-mkwrapper


Regards
Alexander

schoo...@btinternet.com

unread,
Nov 23, 2014, 12:13:16 PM11/23/14
to machi...@googlegroups.com
Hi Alex
> 1) If there is an error in the gcode, upon initial load, the error is
> reported as being on line '-2'

>> I have not had the time to dig into your widgets to see the underlying
>> code regards 1)
>> The initial error will come from the interpreter, but unsure what
>> formatting takes place before display
>> I will report back if I trace what is causing it
> Take a look at:
> https://github.com/machinekit/machinekit/blob/master/src/machinetalk/mkwrapper/mkwrapper.py#L210
> The preview interpreter is generating the error message. The preview
> interpreter in general is not very polished yet.
>
The only thing I can determine from all the parseltongue is that
previewmodule.cc
is returning -1 at L1068

PyTuple_SetItem(retval, 1, PyInt_FromLong(last_sequence_number +
error_line_offset));

and mkwrapper.py L201 is subtracting 1 from it to make it -2

def run(self):
self.isRunning = True
try:
result, last_sequence_number = preview.parse(self.filename,
self.canon,
self.unitcode,
self.initcode)

if result > preview.MIN_ERROR:
error = " gcode error: %s " % (preview.strerror(result))
line = last_sequence_number - 1
if self.debug:
print(("preview: " + self.filename))
print((error + " on line " + str(line)))

Why the preview is essentially returning an error code rather than a
line in the first place I don't know

When it comes down to python libraries implemented in psuedo C++ where
the class member which processes the call,
does not even match the name of the member being called, I start to lose it.

regards



Alexander Rössler

unread,
Nov 23, 2014, 12:38:18 PM11/23/14
to machi...@googlegroups.com
I think it returns -1 when the error is related to reading or opening the
file. So the error should be handled differently if previewmodule returns -1.
When do you get this error?

Regards
Alexander

schoo...@btinternet.com

unread,
Nov 23, 2014, 1:43:15 PM11/23/14
to machi...@googlegroups.com
There was no problem opening or finding the files in question. The
files also all opened without error in Axis

It was a variety of causes, M6T2 when tool 2 was not defined (although
tool.tbl was present), 2 modal codes of the same group on the same line
even though I could not see any, etc etc

I will set up a series of tests, with deliberate errors in the gcode and
see if the error is different in any of the cases.
I will forward you the test files also
At least then there will be a repeatable test so we are comparing like
with like.

There is no inferred criticism here, I avoided many problems by
embedding gremlin instead of writing my own preview ( albeit produced
almost as many problems with the bizarre X embedding behavior of gremlin
and associated focus problems) using the existing code to generate it.
Writing a new one is bound to produce problems but necessary to break
away completely from Axis

regards

schoo...@btinternet.com

unread,
Nov 24, 2014, 5:48:22 AM11/24/14
to machi...@googlegroups.com

On 23/11/14 18:43, schoo...@btinternet.com wrote:
> There was no problem opening or finding the files in question. The
> files also all opened without error in Axis
>
> It was a variety of causes, M6T2 when tool 2 was not defined (although
> tool.tbl was present), 2 modal codes of the same group on the same line
> even though I could not see any, etc etc
>
> I will set up a series of tests, with deliberate errors in the gcode
> and see if the error is different in any of the cases.
> I will forward you the test files also
> At least then there will be a repeatable test so we are comparing like
> with like.
>
> There is no inferred criticism here, I avoided many problems by
> embedding gremlin instead of writing my own preview ( albeit produced
> almost as many problems with the bizarre X embedding behavior of
> gremlin and associated focus problems) using the existing code to
> generate it.
> Writing a new one is bound to produce problems but necessary to break
> away completely from Axis
>
> regards
>
Hi Alex

OK, just started with a small gcode file, a simple one I use on my small
mill to warm it up and spread lubricant before milling.
movetest_mill4.ngc

First load of file
*gcode error:**
**Unrecogn**ised gcode **
**on line -2*

This error was never repeated on subsequent loads, so a peculiar one.

Next load of file
*gcode error:**
**Requested tool 2 not found in the tool table**
**on line -2*

tool.tbl contained 4 tools, I replaced the tool.tbl with another which
was formatted in the full manner
ie
T1 P1 X+0 Y+0 Z+0 instead of just 1 1 0 0 0

but next load the result was the same error

If you try to reload the ngc file using the toolbar icon, you get the error
*can't open**
**Unable to open file<>*
and the run button is disabled although the code still shows in the code
browser window

However a full load of the file again works and re-enables the Run
button, albeit produces the tool 2 error again.

The file will run despite the error initially, it produces the manual
tool change dialog at the M6T2 line, but the status bar continues to
show No Tool

The initial load only produces a preview plot for the first 2 moves of
the program and does not show any subsequent ones

Running the program does not produce any trace of the tool path

The Max velocity slider is set for mm/min. The program uses F500
throughout for G1 moves
The velocity display is steady at *8.3318* during G1 moves
ie it is displaying m/min not mm/min (500/60)

Next loaded a simple file to produce a square
square2.ngc

On load the error is
*gcode error:**
**Two g codes from same modal group**
**on line -2*

After some experimentation I found that it thought the first line of G40
and G90, were the same modal group and produced the error
If I split them, one per line the error went away
However if I put them back on the same line and started the file with a
blank line, there was no error either
Perhaps something to do with how the file is read in?

That is probably enough for now
I don't want to 'pee on your parade', some of these things are probably
not implemented or connected up yet

Cetus discovers the machinekit instance and connects via the localhost,
so that side of it is working fine

I will try digging later to see if I can find any of the causes of the above

regards


movetest_mill_4.ngc
square2.ngc

Alexander Rössler

unread,
Nov 24, 2014, 7:15:21 AM11/24/14
to machi...@googlegroups.com
Thank you for investigating in the problems. Some of them where already known
to me. I have added a few issues on GitHub:
https://github.com/strahlex/QtQuickVcp/issues

It would be very nice if you could copy your findings to the related issues so
I can track the problems easier.

Regards
Alexander

schoo...@btinternet.com

unread,
Nov 24, 2014, 8:16:13 AM11/24/14
to machi...@googlegroups.com

> Thank you for investigating in the problems. Some of them where already known
> to me. I have added a few issues on GitHub:
> https://github.com/strahlex/QtQuickVcp/issues
>
> It would be very nice if you could copy your findings to the related issues so
> I can track the problems easier.
>
> Regards
> Alexander
>
All done, cut and pastes from original email

(Quotes the file producing but not added to each issue comment)

regards

schoo...@btinternet.com

unread,
Nov 24, 2014, 8:57:31 AM11/24/14
to machi...@googlegroups.com
On second thoughts, the code needs to be in the issue text
On second thoughts, the code needs to be in the issue text, or in a
couple of days time
when the email is forgotten, I will be the only one who knows what it
contained exactly

Added

schoo...@btinternet.com

unread,
Nov 24, 2014, 12:21:05 PM11/24/14
to machi...@googlegroups.com
In attempting to investigate the below, perfect example of why I find
QtQuick / qml so difficult


>> The Max velocity slider is set for mm/min. The program uses F500
>> throughout for G1 moves
>> The velocity display is steady at *8.3318* during G1 moves
>> ie it is displaying mm/sec not mm/min (500/60)


I can find the implementation of the Vel: readout in
src/applicationcontrols/DigitalControl.qml

Looks more like python than C++, no line termination, relies on indentation?

Loader {

sourceComponent: textLine

onLoaded: {

item.title = "Vel:"

item.type = ""

item.homed = false

item.value = Qt.binding(function(){return droRect.velocity})

}

active: true

visible: !droRect.offsetsVisible && velocityVisible

}

So the readout is being set by droRect.velocity

However grepping Cetus and QtVcp sources fails to find any
class/struct/widget called 'droRect' which has a member called velocity

So where on earth is the code that is setting the value ( which needs
multiplying by 60 to give mm/min instead of the current mm/sec ) ?

regards

Alexander Rössler

unread,
Nov 24, 2014, 2:42:01 PM11/24/14
to machi...@googlegroups.com
On Monday 24 November 2014 17:21:04 schoo...@btinternet.com wrote:
> In attempting to investigate the below, perfect example of why I find
> QtQuick / qml so difficult
Its different than most classic programming languages. You are used to
imperative language where everything is a sequence of executed commands.
See http://en.wikipedia.org/wiki/Declarative_programming

The huge advantage of QML is that there is actually no program flow. So it
scales very well on multi-core architectures. A GPU is a very good parallel
processor and that’s the reason it runs so fast.

> Looks more like python than C++, no line termination, relies on indentation?
Its neither C++ nor Python. And no it does not rely on indentation. Everything
happens on a single line except when you use curly braces.

> Loader {
A Item, basically a object in QML.
>
> sourceComponent: textLine
property binding
>
> onLoaded: {
function and here it is imperative, JavaScript
>
> item.title = "Vel:"
>
> item.type = ""
>
> item.homed = false
>
> item.value = Qt.binding(function(){return
> droRect.velocity})
>
> }
imperative part is over
>
> active: true
property binding
>
> visible: !droRect.offsetsVisible && velocityVisible
property binding
>
> }
end of Item

> So the readout is being set by droRect.velocity
Yes it is a binding to droRect.velocity. You have to look where droRect is
defined. In this case it is the root component of the QML file.

> However grepping Cetus and QtVcp sources fails to find any
> class/struct/widget called 'droRect' which has a member called velocity
Its in that same QML file.

> So where on earth is the code that is setting the value ( which needs
> multiplying by 60 to give mm/min instead of the current mm/sec ) ?
Not a good idea. Some machines use seconds as time unit.

I have already fixed, just need to create commit.

Regards
Alexander

Alexander Rössler

unread,
Nov 24, 2014, 2:50:45 PM11/24/14
to machi...@googlegroups.com
On Monday 24 November 2014 17:21:04 schoo...@btinternet.com wrote:
Here is the commit that fixed the problem:
https://github.com/strahlex/QtQuickVcp/commit/2956c02a8596486d15b97b11e5891a2894962a03

Regards
Alexander

Marius Alksnys

unread,
Nov 25, 2014, 12:12:34 AM11/25/14
to machi...@googlegroups.com
Alex, the things you create are so great and cool! Thanks.

I would like to try your new interfaces, but I don't fully understand your instructions for testing mkwrapper.
I flashed my BBB 4GB eMMC from given image, ran apt-get update, upgrade and dist-upgrade. I can run linuxcnc locally or remotely, but this is what I get trying to run your .py file for Cetus:
machinekit@beaglebone:~/machinekit-dev/configs/cnc2$ ./launch.py Traceback (most recent call last):
  File "./launch.py", line 7, in <module>
    from machinekit import launcher
ImportError: No module named machinekit

schoo...@btinternet.com

unread,
Nov 25, 2014, 4:11:34 AM11/25/14
to machi...@googlegroups.com
Hi Alex

>> However grepping Cetus and QtVcp sources fails to find any
>> class/struct/widget called 'droRect' which has a member called velocity

> Its in that same QML file.
Now that I have seen your commit, I can see it, but I did not recognise
it as a variable declaration from this

"property double velocity: _ready ? status.motion.currentVel : 15.4"

It seems to be a conditional allocation which says
if(_ready)
velocity = status.motion.currentVel
else
velocity = 15.4

Unless the meaning of the C ? : operators has been changed too

In which case why 15.4?
99999 or 0.0000 I could understand if the widget was not ready, but 15.4?
>> So where on earth is the code that is setting the value ( which needs
>> multiplying by 60 to give mm/min instead of the current mm/sec ) ?
> Not a good idea. Some machines use seconds as time unit.
The target audience for Cetus is presumably Axis users, who use cast
iron, or at least aluminium, with cutting tools, rotating spindles etc
and associated forces.
They will not be using seconds

On a more basic level, a readout should be in the units that were
programmed in

If you use F500, you expect a velocity display to show 500 not 8.3318
>
> I have already fixed, just need to create commit.
>
>
Seen that thanks, when I have more time I will look at something else
and doubtless be back to annoy you further:-P

regards

Alexander Rössler

unread,
Nov 25, 2014, 5:28:43 AM11/25/14
to machi...@googlegroups.com
On Tuesday 25 November 2014 09:11:32 schoo...@btinternet.com wrote:
> In which case why 15.4?
> 99999 or 0.0000 I could understand if the widget was not ready, but 15.4?
The widget should be never not ready on a running machine. If that happens the
widget is grayed out. The values are for testing the widgets. 0.0 makes more
sense, but there was a reason for a value that is not 0.0 at implementation
time. I look over all widgets when I have some time and make the defaults more
sane.

> The target audience for Cetus is presumably Axis users, who use cast
> iron, or at least aluminium, with cutting tools, rotating spindles etc
> and associated forces.
> They will not be using seconds
But the DigitalReadOut can be used for other types of machines that use
seconds as time unit. For example in Machineface for 3D printers.

I take all the values from the linuxcnc Python component and as you see the
units of these values are not consistent at all. That leads to some dirty
hacks that I do not like either. When we remove NML we will replace it with
something more sane. (I have no idea why they used seconds for the values when
there was no way to display velocities in mm/s)

Regards
Alexander

Alexander Rössler

unread,
Nov 25, 2014, 6:00:01 AM11/25/14
to machi...@googlegroups.com
I guess you have downloaded the Machinekit image from Mai right? This image is
outdated. Please follow this guide to get a recent Machinekit installation on
you BBB: https://github.com/strahlex/asciidoc-sandbox/wiki/Creating-a-Machinekit-Debian-Image

We are working on better documentation right now. Feel free to give us
feedback.

Regards
Alexander

schoo...@btinternet.com

unread,
Nov 25, 2014, 6:24:44 AM11/25/14
to machi...@googlegroups.com
Next issue

The failure to reload #14
(duplicated in repo issues)

Did some debugging and the problem is indeed that a blank file name is
being passed to
QApplicationCommand::openProgram()

The below output shows file open after homing - OK
The file name requested to be loaded is shown

Attempt at reload through ReopenAction fails and the debug output shows
the string is empty

Load the file again via the OpenAction and is OK again

'''

qml: Source changed: qrc:///Cetus/Cetus.qml true

qml: Window Cetus loaded

[I 14-11-25 10:58:02] 127.0.0.1:35356-[] FTP session opened (connect)

[I 14-11-25 10:58:02] 127.0.0.1:35356-[anonymous] USER 'anonymous' logged in.

(Initial file load)

QIODevice::read: device not open

[I 14-11-25 10:58:02] 127.0.0.1:35356-[anonymous] STOR /media/sdc/sdc2/root/emc2/ngc/square2.ngc completed=1 bytes=191 seconds=0.001

File name= file:///root/emc2/ngc/square2.ngc

[I 14-11-25 10:58:02] 127.0.0.1:35356-[anonymous] FTP session closed (disconnect).

(Reload tried here)

File name= ""

emc/task/emctask.cc 389: interp_error: Unable to open file <>

Unable to open file <>

can't open

[I 14-11-25 10:59:21] 127.0.0.1:35358-[] FTP session opened (connect)

[I 14-11-25 10:59:21] 127.0.0.1:35358-[anonymous] USER 'anonymous' logged in.

(Loaded again )

QIODevice::read: device not open

[I 14-11-25 10:59:21] 127.0.0.1:35358-[anonymous] STOR /media/sdc/sdc2/root/emc2/ngc/square2.ngc completed=1 bytes=191 seconds=0.001

File name= file:///root/emc2/ngc/square2.ngc

[I 14-11-25 10:59:21] 127.0.0.1:35358-[anonymous] FTP session closed (disconnect).

'''

Having great difficulty finding where
command.openProgram('execute', file.fileName)
is getting *file* from.
grepping is no good because there are so many references littered across
the code

regards


Alexander Rössler

unread,
Nov 26, 2014, 4:46:53 AM11/26/14
to machi...@googlegroups.com
This one should be fixed now.

Regards
Alexander

schoo...@btinternet.com

unread,
Nov 26, 2014, 6:19:16 AM11/26/14
to machi...@googlegroups.com
Well done

Doing other stuff for a while, will do a fresh pull and revisit in due
course

fr...@franksworkshop.com.au

unread,
Nov 26, 2014, 3:35:43 PM11/26/14
to machi...@googlegroups.com
How do I get this to work on a BBB?
 
I got as far as trying to compile the latest version of qt-creator, but it failed when compiling "botan" - the error said the architecture was not supported.
 
Is there a fix, or a work around?
 
My plan is to run QtQuickVcp+ all locally on the BBB.

Alexander Rössler

unread,
Nov 26, 2014, 5:34:20 PM11/26/14
to machi...@googlegroups.com
Have you tried it with Qt4 on the Debian Wheezy BBB image? Then this error is
correct.

QtQuickVcp needs at least Qt5.2. That means you should be able to compile on
the experimental Debian Jessie BBB images with LXQt. If you get the Jessie
image running just ask me how to proceed. I would love to see it running
native on the BBB.

Regards
Alexander

GP Orcullo

unread,
Nov 26, 2014, 5:39:34 PM11/26/14
to Alexander Rössler, Machinekit List
Using Qt5 from wheezy-backports also works.

> Regards
> Alexander
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.


--
GP Orcullo

Alexander Rössler

unread,
Nov 26, 2014, 7:00:41 PM11/26/14