[Emc-users] configuration via Gschem

[Nicklas Karlsson]

I reached a point there I could start to think more about the configuration. I tried the gschem approach and could generate a hal file. The small python script convert the geda netlist into a hal file.

I have seen rockhopper and approach is similar as a printer connected to the network but I do not know about possibility to change the graphs but in general web based applications use to be rather limited then it come to user interfaces, usually only like a form with a loong delay.


Gschem is made for drawing schematics, are there any interest from someone else to get this into a usable state?



Regards Nicklas Karlsson

[Gene Heskett]

Post by Nicklas Karlsson
I reached a point there I could start to think more about the
configuration. I tried the gschem approach and could generate a hal
file. The small python script convert the geda netlist into a hal
file.
I have seen rockhopper and approach is similar as a printer connected
to the network but I do not know about possibility to change the
graphs but in general web based applications use to be rather limited
then it come to user interfaces, usually only like a form with a loong
delay.
Gschem is made for drawing schematics, are there any interest from
someone else to get this into a usable state?

Gschem is for schematics.

I don't figure I can learn a lot from any of the so-called gui helpers
because they also limit what you can do, while hiding the loose nuts and
bolts.

I do my config files(.ini, .xml, .hal, sometimes even the .py's) all with
geany. I may, and have many times when the man page is too concise, ask
for clarification. But when it runs to suit me, I have a fairly decent
understanding of what it is that I have done, and better yet, when it
doesn't do as I expect, a pretty good idea of where to look, finding a
typo is killing something enough times that I could stand to see if
typing lessons could slow some of the typo's caused by my never having
learned to touch type in the first place.

Being self-taught has its advantages, provided one is not afraid to
search for the answers. Nowdays, the problem is remembering the answer
with 80+ yo wet ram. And that can be and is a major frustration
entirely too often.

Post by Nicklas Karlsson
Regards Nicklas Karlsson

Cheers, Gene Heskett

[Nicklas Karlsson]

On Thu, 13 Jul 2017 17:26:15 -0400

Post by Gene Heskett

Post by Nicklas Karlsson
I reached a point there I could start to think more about the
configuration. I tried the gschem approach and could generate a hal
file. The small python script convert the geda netlist into a hal
file.
I have seen rockhopper and approach is similar as a printer connected
to the network but I do not know about possibility to change the
graphs but in general web based applications use to be rather limited
then it come to user interfaces, usually only like a form with a loong
delay.
Gschem is made for drawing schematics, are there any interest from
someone else to get this into a usable state?

Gschem is for schematics.

Yes gschem is for schematics it is possible to generate a netlist from the schematic and the *.hal file is almost a netlist although there are some other commands.

It will give a clear picture of how the blocks are connected.

[andy pugh]

Post by Nicklas Karlsson
I reached a point there I could start to think more about the configuration. I tried the gschem approach and could generate a hal file. The small python script convert the geda netlist into a hal file.

The stuff here?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGschem

[Nicklas Karlsson]

On Thu, 13 Jul 2017 22:34:10 +0100

Post by andy pugh

Post by Nicklas Karlsson
I reached a point there I could start to think more about the configuration. I tried the gschem approach and could generate a hal file. The small python script convert the geda netlist into a hal file.

The stuff here?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGschem

Yes, there is symbols and the short script seems to work then fed with the geda netlist from gnetlist.

An ordinary schematic will give a good picture of the signal paths. Hierarchy is supported so it should be possible to hide the blocks within a hirerchical symbols for constants and only signals coming out. It could also be used to draw the cables, there are several other backends most notably for design of circuit boards.

I used it for circuit boards and started to give it a try for cables.


Nicklas Karlsson

[Nicklas Karlsson]

I started on new scheme backend for gschem, the attached gnet-linuxcnc.scm file, gnetlist option -L. could be used to make it show up among the other backends if file is stored in current directory.

It does halfile:
1. Add the loadrt rows.
2. Threads with automatic numbering of instances.
3. The netlist.

Missing:
1. Parameter symbol?
2. setp for parameters.
3. Hierarchy have some problems, this is useful to put parameters inside hal component.
4. Possibility to set parameters for loadrt.
5. Only default servo-thread, others are ignored.
6. Thread symbol should be one output several inputs.
7. init file is not generated.
8. Symbol with custom rows?

I have some problems with the scheme language but otherwise it will probably not be to hard to get something useful.


Nicklas Karlsson



On Thu, 13 Jul 2017 22:34:10 +0100

Post by andy pugh

Post by Nicklas Karlsson
I reached a point there I could start to think more about the configuration. I tried the gschem approach and could generate a hal file. The small python script convert the geda netlist into a hal file.

The stuff here?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGschem
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/emc-users

[Nicklas Karlsson]

Post by TJoseph Powderly
...
but if you want some geda symbols or testing, I will help

As is now pins have some not necessary attributes but to start with I must figure out which attributes are necessary. I figured out attributes "loadrt" and "thread" might be useful. If attributes exist and are empty default behavior could be used but to override with "none" or any other value might be useful, "?" where number of instances should be inserted might be useful.

I have figured out a top level symbol with a schematic below to hide parameters is useful but guess there are more. I started to draw configuration for one of the machines and will probably figure out more during this. I am not totally sure which part should be source of the servo thread and have seen the servo period is specified then emcmot is loaded.

For constant parameters I guess a simple symbol would work perfectly well.


Nicklas Karlsson

[Nicklas Karlsson]

Post by andy pugh

Post by Nicklas Karlsson
I reached a point there I could start to think more about the configuration. I tried the gschem approach and could generate a hal file. The small python script convert the geda netlist into a hal file.

The stuff here?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGschem

Attached picture correspond almost to my configuration of four axis machine although I have som more IO and others and setp is missing. For axis and step blocks there are a schematic hidden below there constant parameters for the blocks should be set.

Major obstacle before usable state is some problem with hierarchy and generate setp rows, it does not feel to bad in two days.


Nicklas Karlsson

[Gene Heskett]

Post by Nicklas Karlsson

Post by andy pugh

Post by Nicklas Karlsson
I reached a point there I could start to think more about the
configuration. I tried the gschem approach and could generate a
hal file. The small python script convert the geda netlist into a
hal file.

The stuff here?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGschem

Attached picture correspond almost to my configuration of four axis
machine although I have som more IO and others and setp is missing.
For axis and step blocks there are a schematic hidden below there
constant parameters for the blocks should be set.
Major obstacle before usable state is some problem with hierarchy and
generate setp rows, it does not feel to bad in two days.
Nicklas Karlsson

The .png cannot be zoomed to inspect details, but for 2 days work, looks
better than I expected. And thats encouraging.

Are you intending to be able to translate an existing, working config
into this, and to be able to take this back to working .ini + .hal
files?

Not necessarily the originals, but perhaps order optimized that still do
the exact same job? That would, I believe, make logic mistakes in the
original .hal easier to spot. Face-palm moments, those. :-)

Cheers, Gene Heskett

[Jon Elson]

Post by Gene Heskett
The .png cannot be zoomed to inspect details, but for 2 days work, looks
better than I expected. And thats encouraging.
Are you intending to be able to translate an existing, working config
into this, and to be able to take this back to working .ini + .hal
files?

I'm afraid when all the signals are wired up, your drawing
is going to get very "busy".
But, for people who want to work with the config this way,
it may be quite useful.

Jon

[Nicklas Karlsson]

Post by Gene Heskett

Post by andy pugh
...
The stuff here?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGschem

...

...
Are you intending to be able to translate an existing, working config
into this, and to be able to take this back to working .ini + .hal
files?

No translation of existing config is planned because I expect it would be hard to place the symbols and nets. It should be used to make configuration file.

it should probably be rather straight forward to implement feedback of attribute values if there is a use for it.

Post by Gene Heskett
Not necessarily the originals, but perhaps order optimized that still do
the exact same job? That would, I believe, make logic mistakes in the
original .hal easier to spot. Face-palm moments, those. :-)

I anyone who make circuit boards by writing the netlist and feed it into the layout program. As is now the *.hal file is almost only about connecting the pins.

[Gene Heskett]

Post by Nicklas Karlsson

Post by Gene Heskett

Post by andy pugh
...
The stuff here?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGsche
m

...

...
Are you intending to be able to translate an existing, working
config into this, and to be able to take this back to working .ini +
.hal files?

No translation of existing config is planned because I expect it would
be hard to place the symbols and nets. It should be used to make
configuration file.
it should probably be rather straight forward to implement feedback of
attribute values if there is a use for it.

Post by Gene Heskett
Not necessarily the originals, but perhaps order optimized that
still do the exact same job? That would, I believe, make logic
mistakes in the original .hal easier to spot. Face-palm moments,
those. :-)

I anyone who make circuit boards by writing the netlist and feed it
into the layout program. As is now the *.hal file is almost only about
connecting the pins.

I have a somewhat broader view of a hal file. I tend to build the logic I
need, then treat it as a logic block, at least in my mind. But I try to
keep that function block in a single, hopefully well commented stanza of
the hal file so if I have to go back later and "fix it", I have as much
of it as will fit on screen, in one screen full. I don't always succeed
of course. :)

Post by Nicklas Karlsson
----------------------------------------------------------------------
-------- 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
https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene Heskett

[Nicklas Karlsson]

Post by Gene Heskett
The .png cannot be zoomed to inspect details, but for 2 days work, looks
better than I expected. And thats encouraging.

Somebody started it earlier I think it TJoseph Powderly but I continued it now.

Post by Gene Heskett
Are you intending to be able to translate an existing, working config
into this, and to be able to take this back to working .ini + .hal
files?

It is interesting rockhopper do this but I do not figure out how they automatically place the blocks and connections. It would be useful to populate the library of available hal components from a running system.

I intend to do configuration graphically while rockhopper have manual editing of the config file. Even though the approach with gschem does not end up to be good enough it still a good way to figure out how it should be done, it may also be used for cables and I use it for circuit boards.

[Nicklas Karlsson]

On Sat, 15 Jul 2017 11:57:02 -0400

Post by andy pugh

Post by Nicklas Karlsson
I reached a point there I could start to think more about the
configuration. I tried the gschem approach and could generate a
hal file. The small python script convert the geda netlist into a
hal file.

The stuff here?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGschem

I did some changes to this and modified one of the ordinary backends for gschem. I think it generate something useful right now but with a known bug for counting used for loadrt.

loadrt is hardcoded, there are restrictions on refdes names, hierarchy and a few other problems, no *.ini file generated. I will think about it for a while before I return but if anyone is interested I could send it?


Nicklas Karlsson

[Nicklas Karlsson]

Post by andy pugh

Post by Nicklas Karlsson
I reached a point there I could start to think more about the configuration. I tried the gschem approach and could generate a hal file. The small python script convert the geda netlist into a hal file.

The stuff here?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGschem

Attached picture correspond almost to my configuration of four axis machine although I have som more IO and others and setp is missing. For axis and step blocks there are a schematic hidden below there constant parameters for the blocks should be set.

Major obstacle before usable state is some problem with hierarchy and generate setp rows, it does not feel to bad in two days.


Nicklas Karlsson

[TJoseph Powderly]

(sorry, looks like i made a private reply to andy and not to the list,
so here's the msg)

I wrote that stuff for geda
i havent looked at it for years
I was dissapointed in the zoom and pan, and how to graphically handle
the threads
so i wandered off looking at other connected box frameworks
ths morning as i looked at Node-Red's audio kit for Teensy ( a cnxd box
gui )
https://www.pjrc.com/teensy/gui/
this email arrived,
odd coincidence

most guis have limitations, such as:
only 1 output
inputs only on one side
labeled nets
draggable elements
saving edits
netsfile->graphic->netfile
java dependancies (self imposed limitation)
lacking scaling of image
lacking meta-components aids in scaling issues)

i wanted a perfect solution and decided to lower my expectations (TM SNL)
i think it may be useful to use geda-schem to illustrate some conncetions
ditto for rockhopper and the eagle for hal effort
but i see no solution for a full netlist->graphic editor->netlist

Lift Architects of Boston did a rear projected FTIR touchtable for
grasshopper diagrams
( connected boxes for rhino ), and that was the closest thing to my
dream so far. Users
could pinch and scroll and zoom a screen nearly 20"x80" to view the
diagrams. I cant find the
videos now, maybe they are Vimeo not youtube.
yep
https://vimeo.com/72447811


oh,its best to reiterate the basic idea
long lists of driving instructions suck, maps rule
long net lists suck, diagrams rule
short & sweet
regards
tomp tjtr33

[TJoseph Powderly]

wow nicklas
i poked at scheme many years ago
out came crawling, some lamdas, cdrs and cars
i ran away

you're brave
i wont wade into those waters,
but if you want some geda symbols or testing, I will help

tomp tjtr33

[Nicklas Karlsson]

Post by TJoseph Powderly
you're brave
i wont wade into those waters,
but if you want some geda symbols or testing, I will help

I assumed all added symbols should have loadrt and a thread but this is not always the case.

I guess the following pin attributes would make sense:
"setp" would ideally drive the net with value attribute as argument or generate a setp?
"addf" would generate addf with thread driving the net as argument.

loadrt is a little bit harder. I guess a floating attribute would make sense but while most often count is used as argument there are exceptions.


Nicklas Karlsson

[andy pugh]

Post by Nicklas Karlsson
I assumed all added symbols should have loadrt and a thread but this is not always the case.

There are only really three options in common use. loadrt / addf to
the base thread, loadrt / addf to the servo thread and loadusr.

One way to handle that might be to drop the functions into one of
three re-sizable panes on the screen.

I wonder if Scilab is a better fit? I have coded real-time systems in LabVIEW.

(A large proportion of the real-time code at work is compiled directly
from Simulink models, and that that isn't is documented in Ascet
diagrams.)

[Nicklas Karlsson]

Post by andy pugh

Post by Nicklas Karlsson
I assumed all added symbols should have loadrt and a thread but this is not always the case.

There are only really three options in common use. loadrt / addf to
the base thread, loadrt / addf to the servo thread and loadusr.
One way to handle that might be to drop the functions into one of
three re-sizable panes on the screen.
I wonder if Scilab is a better fit? I have coded real-time systems in LabVIEW.

They are not to different in an electric network a signal is driven from one source and the same apply for xcos in Scilab or Simulink. I guess all blocks could be expressed a function called at regular intervals and the lines decide from which input the arguments should come.

Gschem is also to some extent suitable for cable drawings so I it might be a better choice because of this. As is now I stick with gschem because it is rather close to be useful. With the correct symbols I guess it would be possible to generate a netlist suitable for Xcos or Simulink style simulation although spice is maybe not useful.

Post by andy pugh
(A large proportion of the real-time code at work is compiled directly
from Simulink models, and that that isn't is documented in Ascet
diagrams.)

The real time code could quite often be expressed in the form of ordinary algebraic equations. There is input on one side and output on the other and most often in the real system this will end up in a function called at regular intervals.

Some of the blocks in linuxcnc is the same as in Simulink or Scilab xcos but I think there is no hostmot driver in Simulink and it could not generate the *.hal file to connect the blocks or function calls.

[Nicklas Karlsson]

Post by andy pugh

Post by Nicklas Karlsson
I assumed all added symbols should have loadrt and a thread but this is not always the case.

There are only really three options in common use. loadrt / addf to
the base thread, loadrt / addf to the servo thread and loadusr.
One way to handle that might be to drop the functions into one of
three re-sizable panes on the screen.

No I think the functions should be in the block they belong to.
- Thread is connected to a pin so an attribute attached to the actual pin is a natural choice.
- Loadrt is used to load the hal module corresponding to the symbol but all instances of one type is usually loaded at once.
- Loadusr I have not yet looked at.
I think I choose some manual work with the attributes to start with, these may stay to manually override default behaviour later.

Hierarchy almost work if hierachical path is removed, it still make sense since simpler overview is possible. Output pin seems to have problem for some reason and produce wrong netlist.


In a little bit more than one day not more could be expected.



Nicklas Karlsson

[Todd Zuercher]

Not that I understand exactly what you're doing, but it does look very interesting. If you are interested I am sure we could contribute some rather complicated configuration examples for you to play around with for testing. (I know Gene has some doozies, and I have a couple rather twisted ones as well.)

----- Original Message -----
From: "Nicklas Karlsson" <***@gmail.com>
To: "TJoseph Powderly" <***@gmail.com>
Cc: emc-***@lists.sourceforge.net
Sent: Saturday, July 15, 2017 11:04:48 AM
Subject: Re: [Emc-users] configuration via Gschem

Post by TJoseph Powderly
...
but if you want some geda symbols or testing, I will help

As is now pins have some not necessary attributes but to start with I must figure out which attributes are necessary. I figured out attributes "loadrt" and "thread" might be useful. If attributes exist and are empty default behavior could be used but to override with "none" or any other value might be useful, "?" where number of instances should be inserted might be useful.

I have figured out a top level symbol with a schematic below to hide parameters is useful but guess there are more. I started to draw configuration for one of the machines and will probably figure out more during this. I am not totally sure which part should be source of the servo thread and have seen the servo period is specified then emcmot is loaded.

For constant parameters I guess a simple symbol would work perfectly well.


Nicklas Karlsson

------------------------------------------------------------------------------
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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Jon Elson]

Post by Todd Zuercher
Not that I understand exactly what you're doing, but it does look very interesting. If you are interested I am sure we could contribute some rather complicated configuration examples for you to play around with for testing. (I know Gene has some doozies, and I have a couple rather twisted ones as well.)

OK, one other monkey wrench is that some systems require
that certain addf's be done in a specific order.
That is true of my Pico Systems configs, certain things need
to be done in the right order of you will not be able to get
out of E-stop. The hal component that checks the E-stop
condition needs to be BEFORE the thing that writes it, so
that it gets a full servo cycle delay for the hardware to
come out of E-stop before checking status again. Or, does
what you are doing ONLY deal with nets, pins and signals,
and you still need some other way to create the loadrt's and
addf's?

Jon

[Nicklas Karlsson]

Post by Jon Elson

Post by Todd Zuercher
Not that I understand exactly what you're doing, but it does look very interesting. If you are interested I am sure we could contribute some rather complicated configuration examples for you to play around with for testing. (I know Gene has some doozies, and I have a couple rather twisted ones as well.)

OK, one other monkey wrench is that some systems require
that certain addf's be done in a specific order.
That is true of my Pico Systems configs, certain things need
to be done in the right order of you will not be able to get
out of E-stop. The hal component that checks the E-stop
condition needs to be BEFORE the thing that writes it, so
that it gets a full servo cycle delay for the hardware to
come out of E-stop before checking status again. Or, does
what you are doing ONLY deal with nets, pins and signals,
and you still need some other way to create the loadrt's and
addf's?

No I did not think about order but an attribute could be added to get correct order. My configuration I think always produce one real time delay at startup and this might be because of the order problem.

At first I thought all the connections where made before the system started.

[Gene Heskett]

Post by Todd Zuercher
Not that I understand exactly what you're doing, but it does look very
interesting. If you are interested I am sure we could contribute some
rather complicated configuration examples for you to play around with
for testing. (I know Gene has some doozies, and I have a couple
rather twisted ones as well.)

As I'd suspect w/o too many more clues, Todd. This one for the Sheldon
isn't the longest one in my zoo, but if comment lines are skipped, I
believe its still under 500 LOC for the main .hal file. Screen updates
in the postgui stuff are I believe that main reason for over-runs as the
pi's video is framebuffer=damned slow. One of the reasons I am
considering a rock64, its cpu is about 30% faster, and can be had with
4Gb of dram @ $44.95. Throw in 500 MHz two channel mali gfx and it has
to be a winner once the infant mortality stuff is fixed. And even if the
storage path is still thru the usb like on the pi's, its a usb3 sized
porthole. Ethernet is also up to a gigabit.

Servo-thread execution times are piling up on the pi though. Which is
why the dial stuff runs in its own 100 hz jog-thread. That seems to be
more than fast enough to keep up with the dials.

If anyone is curious, append lathe-stf/sheldon-lathe-config/ to the link
in my sig for downloadable access to a copy of that config as it exists
today.

Post by Todd Zuercher
----- Original Message -----
Sent: Saturday, July 15, 2017 11:04:48 AM
Subject: Re: [Emc-users] configuration via Gschem

Post by TJoseph Powderly
...
but if you want some geda symbols or testing, I will help

As is now pins have some not necessary attributes but to start with I
must figure out which attributes are necessary. I figured out
attributes "loadrt" and "thread" might be useful. If attributes exist
and are empty default behavior could be used but to override with
"none" or any other value might be useful, "?" where number of
instances should be inserted might be useful.
I have figured out a top level symbol with a schematic below to hide
parameters is useful but guess there are more. I started to draw
configuration for one of the machines and will probably figure out
more during this. I am not totally sure which part should be source of
the servo thread and have seen the servo period is specified then
emcmot is loaded.
For constant parameters I guess a simple symbol would work perfectly well.
Nicklas Karlsson
----------------------------------------------------------------------
-------- 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
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
https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene Heskett

[Erik Christiansen]

Screen updates in the postgui stuff are I believe that main reason for
over-runs as the pi's video is framebuffer=damned slow. One of the
reasons I am considering a rock64, its cpu is about 30% faster, and

The only thing is that 30% faster than glacial still isn't up to some of
the motorin' of your youth, Gene. At this link:
https://www.udoo.org/forum/threads/rpi-3-vs-udoo-x86-cpu-benchmarks.7326/
we have some runs of:
"sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run"
which summarise as:

Raspberry Pi 3 Model B (Raspbian Jessie, sysbench 0.4.12) 119.6545s
Udoo X86 Ultra (Debian Stretch, sysbench 0.4.12) 12.1223s
Udoo X86 Advanced on Ubuntu 16.04 LTS 14.6706s
Udoo X86 Advanced on Ubuntu 16.10 LTS, on on-board emmc 15.5837s
Udoo Basic, FreeBSD 11-RELEASE-p1 29.5172s
Here it is for an "older" up board (1) 15.0586s

Did you hook an Up board onto the conveyor of goods headed out your way,
Gene, or was that one that got away?

I just ran it on my Udoo X86 Advanced, and it gives 22.3 seconds. That
seems out of whack with the other results. Mind you, it didn't start the
fan, so may be still in first gear.

Erik

[andy pugh]

Post by Erik Christiansen
I just ran it on my Udoo X86 Advanced, and it gives 22.3 seconds.

Have you found a way to make use of the Udon "Arduino" co-processor in
a LinuxCNC context?

[Erik Christiansen]

Post by andy pugh

Post by Erik Christiansen
I just ran it on my Udoo X86 Advanced, and it gives 22.3 seconds.

I've since seen that there is a fourth variant, the Advanced+, and that
is the one with the 14-15 second performance.

Post by andy pugh
Have you found a way to make use of the Udon "Arduino" co-processor in
a LinuxCNC context?

The thing only arrived a couple of days ago, and it was a fight just to
get audio to work on the HDMI, due to obfuscation in the perverse GUI
design of "PulseAudio Volume Control" on Debian 9.0.0, where the vital
tab was omitted from display, despite no reason to show just 3 of 5 tabs.

Now that it basically works, I'll have to find time to play with it, but
completing plans for the new workshop/garage/accommodation out on the
farm, plus heading out there to expedite things like the now-mandatory
Bushfire Attack Level assessment, takes priority¹. And then there's
refurbishing this place, prior to sale, in parallel with managing the
project out there, as an owner-builder. (Second time around, I'm the
architect too. What could possibly tie up my time? :)

It would be fun to see what could be done with the "Arduino" half of the
board. It's not an AVR, though, but an "Intel® Quark SE core 32 MHz plus
32-bit ARC core 32 MHz", whatever that is. It has 14 digital + 6
analogue (10 bit) pins.

As it comes out of a "maker" community, I suspect that it won't compete
with the Beaglebone's two 32 bit PRUs, or their interconnection
bandwidth. The interface seems to be USB:

https://www.udoo.org/docs-x86/Arduino_101_%28Intel_Curie%29/Overview.html

The 3 external USB interfaces are USB3, so the on-board one _might_ be?
https://www.udoo.org/docs-x86/Hardware_Reference/Overview.html says:
"The communications between the Braswell SOC and the CurieTM SOC come
through a USB interface, exactly like Arduino 101 / Genuino 101 boards
connect to external PCs."

That sounds rather like the Udoo Quad you tried, and put away in a
drawer somewhere?

For some funny reason, I'm predisposed to just ordering a Beaglebone
(with those nifty PRUs as powerful & flexible PWM/whatever generators)
and leveraging all the work already done there. I'm not married to the
concept of "The whole wedding cake on one tray." when a Beaglebone in a
compact enclosure near the drives can do the RT stuff, and e.g. a Udoo
X86 can deliver the remote UI, with TP output queued on the RT host, so
the ethernet or RS485 in between has little in the way of latency demands.
(Though that architecture should also work across the inter-processor
USB link on a Udoo board.)

Erik

¹ The soil test is done, so slab design can proceed. Yay!
Have to check first that the roof trusses won't need any of the
interior walls to be loadbearing, though. (I.e. spans are good to go.)

[Gene Heskett]

Post by Erik Christiansen

Screen updates in the postgui stuff are I believe that main reason
for over-runs as the pi's video is framebuffer=damned slow. One of
the reasons I am considering a rock64, its cpu is about 30% faster,

The only thing is that 30% faster than glacial still isn't up to some
https://www.udoo.org/forum/threads/rpi-3-vs-udoo-x86-cpu-benchmarks.73
"sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run"
Raspberry Pi 3 Model B (Raspbian Jessie, sysbench 0.4.12) 119.6545s
Udoo X86 Ultra (Debian Stretch, sysbench 0.4.12) 12.1223s
Udoo X86 Advanced on Ubuntu 16.04 LTS 14.6706s
Udoo X86 Advanced on Ubuntu 16.10 LTS, on on-board emmc 15.5837s
Udoo Basic, FreeBSD 11-RELEASE-p1 29.5172s
Here it is for an "older" up board (1) 15.0586s
Did you hook an Up board onto the conveyor of goods headed out your
way, Gene, or was that one that got away?
I just ran it on my Udoo X86 Advanced, and it gives 22.3 seconds. That
seems out of whack with the other results. Mind you, it didn't start
the fan, so may be still in first gear.
Erik

I did get an up board. SOB has a uefi bios, and would not boot anything I
tried. So I went trolling thru the bios looking for a way to turn that
crap off. The only thing I could find was to disable the tcp chip.
Bricked it. According to their web site, a $400 jtag programmer and an
80 dollar adapter are needed to rewrite the bios in that event.
Questions beyond that on the forum have been ignored. IOW, that board,
while seemingly have great specs, has a windows only attitude. UP is
otherwise totally unresponsive to users problem.

As far as I'm concerned, I got screwed out of a 100 dollar bill and a
week.

The last price I saw for a Udoo was in the neighborhood of 150 dollars. I
can get a std mobo, with cpu and enough memory for that. So 4 questions
now that its shipping:

1. Udoo X86 Ultra, $267.00 on the Udoo site today. Thats not even close
to realistic. The dual/quad is $135 but I can't find any other data on
it quickly. Ah, its an arm, claims to be an rpi3 performance wise.

2. can any UEFI bios BS be turned off w/o bricking it?

3. Does it have a working spi driver so I don't have to throw away $250
in interfacing hardware and start writing my configs all over again? The
spi must be clocked at at least 25 mhz. Alternatively, can it emulate
an EPP port at equ of 5 megabytes a second both ways?

4. How big is it?

Their site is slow, and has this annoying pop-over asking where you are
nearly everytime you switch pages. All the specs are buried in a pdf
download which is near impossible to read as they chose a very light
color on a white background for the text. That tells me they have
something to hide. I did find the size, about an inch bigger than the
pi, both ways.

All of this is why I'll be watching the rock64 board at $44 fully
stuffed, Claims it doesn't have the pi's i/o bottleneck. And that would
be huge.

Thanks Erik.

Cheers, Gene Heskett

[Erik Christiansen]

Post by Gene Heskett
I did get an up board. SOB has a uefi bios, and would not boot anything I
tried. So I went trolling thru the bios looking for a way to turn that
crap off. The only thing I could find was to disable the tcp chip.
Bricked it. According to their web site, a $400 jtag programmer and an
80 dollar adapter are needed to rewrite the bios in that event.
Questions beyond that on the forum have been ignored. IOW, that board,
while seemingly have great specs, has a windows only attitude. UP is
otherwise totally unresponsive to users problem.
As far as I'm concerned, I got screwed out of a 100 dollar bill and a
week.

"UP" stands for Unix Prohibited?

Post by Gene Heskett
The last price I saw for a Udoo was in the neighborhood of 150 dollars. I
can get a std mobo, with cpu and enough memory for that. So 4 questions
1. Udoo X86 Ultra, $267.00 on the Udoo site today. Thats not even close
to realistic. The dual/quad is $135 but I can't find any other data on
it quickly. Ah, its an arm, claims to be an rpi3 performance wise.

Yeah, add the optional M.2 on-board SSD, and you're up to around A$400
just for the Advanced, but then ours is only worth 3/4 of one of yours.
And mount that on the back of a monitor, add a wireless keyboard &
mouse, and you're good to go. I don't think there's any need for an
Ultra unless you're into games.

I can't see any sense in buying cheap if all it gets you is another RPi
pig-in-mud. How usable is Machinekit? A Beaglebone is pretty
competitive, isn't it?

Post by Gene Heskett
2. can any UEFI bios BS be turned off w/o bricking it?

I briefly saw some UEFI nonsense while installing debian, told it to
shut up and write the MBR, and I haven't had any problem. I think it
does mean that I can't dual boot MSW, but I've never let that crap into
the house on my boots, anyway.

Post by Gene Heskett
3. Does it have a working spi driver so I don't have to throw away $250
in interfacing hardware and start writing my configs all over again? The
spi must be clocked at at least 25 mhz. Alternatively, can it emulate
an EPP port at equ of 5 megabytes a second both ways?

Interface specs are a bit thin. I don't even know if some of the digital
I/O is on the Braswell (64 bit 4-core X86 host chip) or all on the 32 bit
sidekick. It says: OTHER INTERFACES: Up to 20 external GPIOs
LPC - 2 x I2C - GPIOs - Touch Screen
Management signals on expansion connector

I'm not too clear on the difference between SPI and I²C, so can't
advise.

Post by Gene Heskett
4. How big is it?

It's 4.72 inch x 3.35 inch (12 cm x 8.5 cm). That's as wide as my palm,
and 1.5 times its length - with 256 GB M.2 on-board SSD hard drive included.

Post by Gene Heskett
Their site is slow, and has this annoying pop-over asking where you are
nearly everytime you switch pages. All the specs are buried in a pdf
download which is near impossible to read as they chose a very light
color on a white background for the text. That tells me they have
something to hide. I did find the size, about an inch bigger than the
pi, both ways.

I view the pdf with xpdf, and have set it for a grey background. That's
not perfect with the light colours, but a damned sight better than
white. The inverse video produced when selecting a text block with a
mouse drag is perfectly readable. There's not an excess of "All the
specs", just some basic numbers.

I've never seen any pop-over asking where you are, on that site.

Post by Gene Heskett
All of this is why I'll be watching the rock64 board at $44 fully
stuffed, Claims it doesn't have the pi's i/o bottleneck. And that would
be huge.

Best of luck. I'll be waiting for your review. It could be a good little
unit, if it pans out.

Erik

[Gene Heskett]

Post by Erik Christiansen

Post by Gene Heskett
I did get an up board. SOB has a uefi bios, and would not boot
anything I tried. So I went trolling thru the bios looking for a way
to turn that crap off. The only thing I could find was to disable
the tcp chip. Bricked it. According to their web site, a $400 jtag
programmer and an 80 dollar adapter are needed to rewrite the bios
in that event. Questions beyond that on the forum have been ignored.
IOW, that board, while seemingly have great specs, has a windows
only attitude. UP is otherwise totally unresponsive to users
problem.
As far as I'm concerned, I got screwed out of a 100 dollar bill and
a week.

"UP" stands for Unix Prohibited?

Seems to an accurate description. :)

Post by Erik Christiansen

Post by Gene Heskett
The last price I saw for a Udoo was in the neighborhood of 150
dollars. I can get a std mobo, with cpu and enough memory for that.
1. Udoo X86 Ultra, $267.00 on the Udoo site today. Thats not even
close to realistic. The dual/quad is $135 but I can't find any
other data on it quickly. Ah, its an arm, claims to be an rpi3
performance wise.

Yeah, add the optional M.2 on-board SSD, and you're up to around A$400
just for the Advanced, but then ours is only worth 3/4 of one of
yours. And mount that on the back of a monitor, add a wireless
keyboard & mouse, and you're good to go. I don't think there's any
need for an Ultra unless you're into games.
I can't see any sense in buying cheap if all it gets you is another
RPi pig-in-mud. How usable is Machinekit? A Beaglebone is pretty
competitive, isn't it?

It may have been, were I will to learn a new program. Now I am quite
comfy, although not quite an expert at carving hal stuff, particularly
when the available docs are often lacking an example line to demo the
syntax that is left out of the rest of the docs or man pages. I should
not have to ask for clarification in order to use the modules available.
My most recent question was about the logic level expected at the pin
oneshot.reset, its not stated in the man page. I suspected it needed a
logic one, and I believe it was Andy that confirmed it, so 2 more lines
in my .hal file, and it works as desired. I think the next edits will be
to take the 2 higher speed jogs back out of it as its way too easy
to "wind" it up, limited to available MAX_VEL, and it runs a couple feet
and into something after you've turned it rapidly. There is a mode where
it would stop where ever its at when the dial stops, velocity I think,
but haven't tried to convert the code to do that as I was more
interested in being able to move the absolute distance desired, touch
that off and make the final good fit.

But I found yesterday that the spindle to bed alignment is fubar'd by
several thou a foot. I have not loosened those bolts, but it appears I
need to do some shimming of the head to rear v-way joint. Probably a
piece of 20 lb paper which is 3 or 4 thou thick. I'll turn 3 or 4 inches
clean and measure it before the day is fini, and see if I can calculate
which side of the v-way and how much, to shim it straight. I'll check
the up-down too. I've already put some shims between the tailstock
casting and its bed riding shoe because it was so far out of whack
vertically it was breaking center drills. Might have to sacrifice a
feeler gauge blade to get the correct thickness. They are replaceable a
heck of a lot cheaper than special ordering shim stock from NAPA. :)

Post by Erik Christiansen

Post by Gene Heskett
2. can any UEFI bios BS be turned off w/o bricking it?

I briefly saw some UEFI nonsense while installing debian, told it to
shut up and write the MBR, and I haven't had any problem. I think it
does mean that I can't dual boot MSW, but I've never let that crap
into the house on my boots, anyway.

I couldn't get it to recognize an sd card with an image downloaded from
the UP site on it.

UEFI was blocking access to even read the /boot on the card. And it said
so on screen.

Post by Erik Christiansen

Post by Gene Heskett
3. Does it have a working spi driver so I don't have to throw away
$250 in interfacing hardware and start writing my configs all over
again? The spi must be clocked at at least 25 mhz. Alternatively,
can it emulate an EPP port at equ of 5 megabytes a second both ways?

Interface specs are a bit thin. I don't even know if some of the
digital I/O is on the Braswell (64 bit 4-core X86 host chip) or all on
the 32 bit sidekick. It says: OTHER INTERFACES: Up to 20 external
GPIOs LPC - 2 x I2C - GPIOs - Touch Screen Management signals on
expansion connector
I'm not too clear on the difference between SPI and I²C, so can't
advise.

SPI is a 3 or 4 wire & ground serial interface, clocked (connection 1)
from the pi, individual addressing of up to 4 devices paralleled on the
cable, 2 connections to select the address, and a common data wire, and
with Bertho Stultans new rpspi.so driver, at speeds up to 50 mhz, and
different speeds for read and write. As I understand it, data is clocked
into the 7i90 on one edge of the clock, and the 7i90's response is read
on the other edge. But in my observations, I have not seen any such
interleaved communications. So its a 32 bit packet, going each way, and
may take more than one packet exchange to fully update things. So you
can go as fast as your 7i90 can keep up. Transmit side terminated,
cabling can be longer than the currently 3" mine is. However I have not
explored cable lengths above 7", which didn't seem to effect its max
data rate. Several feet would probably be a different critter,
requiring slower clocking, or a rethinking of the termination method.

Gotta run, the missus would like some breakfast.

Post by Erik Christiansen

Post by Gene Heskett
4. How big is it?

It's 4.72 inch x 3.35 inch (12 cm x 8.5 cm). That's as wide as my
palm, and 1.5 times its length - with 256 GB M.2 on-board SSD hard
drive included.

Post by Gene Heskett
Their site is slow, and has this annoying pop-over asking where you
are nearly everytime you switch pages. All the specs are buried in a
pdf download which is near impossible to read as they chose a very
light color on a white background for the text. That tells me they
have something to hide. I did find the size, about an inch bigger
than the pi, both ways.

I view the pdf with xpdf, and have set it for a grey background.
That's not perfect with the light colours, but a damned sight better
than white. The inverse video produced when selecting a text block
with a mouse drag is perfectly readable. There's not an excess of "All
the specs", just some basic numbers.
I've never seen any pop-over asking where you are, on that site.

Post by Gene Heskett
All of this is why I'll be watching the rock64 board at $44 fully
stuffed, Claims it doesn't have the pi's i/o bottleneck. And that
would be huge.

Best of luck. I'll be waiting for your review. It could be a good
little unit, if it pans out.
Erik
----------------------------------------------------------------------
-------- 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
https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene Heskett

[Jon Elson]

Post by Gene Heskett
It may have been, were I will to learn a new program.

New program? Machinekit IS LinuxCNC, at least as far as the
g-code end of things is.
HAL is the same, Linux is the same. There are significant
differences in rtapi, but few venture into there.
I use it here to run a CRAMPS board test fixture, and
everything I've learned about LinuxCNC is correct.
It does allow you to run software generated stepper systems
a lot better than on the x86, with the PRU feature provided
by Charles Steinkuehler. There are sample configs that make
it totally painless.

I also use Machinekit as my distro of choice for embedded
computing, and have Machinekit installs in a number of
devices that have NOTHING to do with CNC, just because I
know my way around in there.

Jon

[Chris Albertson]

The problem with the Pi3 is that people are trying to simultaneously run
both a real time controller process and a graphic desktop system. Either
of these might work but not both at once.

The Pi3 really is best when run "headless" with no monitor/keyboard/mouse
plugged in.

Real time processes really do need to take priority and this is in direct
conflict with a responsive no-lag graphical interface. The way around it,
is to use a grossly over powered processor, like an Intel powered PC or to
use two processors (like the Pi and maybe a notebook PC) that are only
loosely coupled.

I've been working with small Linux based ARM processors and not just with
MK or CNC work and the above is true in other use cases as well.

For heavy duty graphic that does 3D renders it is good to have a decent
GPU.

Post by Erik Christiansen

Screen updates in the postgui stuff are I believe that main reason for
over-runs as the pi's video is framebuffer=damned slow. One of the
reasons I am considering a rock64, its cpu is about 30% faster, and

The only thing is that 30% faster than glacial still isn't up to some of
https://www.udoo.org/forum/threads/rpi-3-vs-udoo-x86-cpu-benchmarks.7326/
"sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run"
Raspberry Pi 3 Model B (Raspbian Jessie, sysbench 0.4.12) 119.6545s
Udoo X86 Ultra (Debian Stretch, sysbench 0.4.12) 12.1223s
Udoo X86 Advanced on Ubuntu 16.04 LTS 14.6706s
Udoo X86 Advanced on Ubuntu 16.10 LTS, on on-board emmc 15.5837s
Udoo Basic, FreeBSD 11-RELEASE-p1 29.5172s
Here it is for an "older" up board (1) 15.0586s
Did you hook an Up board onto the conveyor of goods headed out your way,
Gene, or was that one that got away?
I just ran it on my Udoo X86 Advanced, and it gives 22.3 seconds. That
seems out of whack with the other results. Mind you, it didn't start the
fan, so may be still in first gear.
Erik
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/emc-users

[Nicklas Karlsson]

Post by Chris Albertson
The problem with the Pi3 is that people are trying to simultaneously run
both a real time controller process and a graphic desktop system. Either
of these might work but not both at once.

Real time is enough and I actually think something slower could be used. Graphics I would say have priority in 20-50ms range so it will work if it does not interfere with high servo period thread but this might be culprit.

Post by Chris Albertson
The Pi3 really is best when run "headless" with no monitor/keyboard/mouse
plugged in.

This is how I plan to use it.

Post by Chris Albertson
For heavy duty graphic that does 3D renders it is good to have a decent
GPU.

Linuxcnc graphic I think is simple, or maybe not the 3D view in gremlin is heavy duty?


Regards Nicklas Karlsson