Re: [Machinekit] Re: MachineKit on BBB running Hostmot2 with Xilinx FPGA

[Jeff Pollard]

Hi,

  I will have to relearn how to do the whole git/pull stuff (which will 
take some time).
  And I will have to clean up the files before I do that...
  In the mean time, if you e-mail me at supp...@xylotex.com I can e-mail 
you the files.
  I have the gpmc access file currently named  hm2_Xi90.c, but that will 
probably change
  That code basically sets up the GPMC bus and provides read/write function 
for the hostmot2 software.  The bit settings for the gpmc configure the bus 
for multiplexed address/data with specific timing that the bitfile in the 
FPGA would expect
  If you are going to use the GPMC you will need to disable the emmc in the 
/boot/uboot/uEnv.txt (or wherever that file is kept these days- I'm still 
working from an old 2015 version of machinekit).
  Then you'll need to get the vhdl file to match the timing generated by 
the gpmc bus.  It's currently called topEPPHostMot2.vhd on my computer, but 
should be renamed to something else as well.  I started with mesa EPP bus 
stuff to make the gpmc interface and haven't renamed the file.  There is a 
lot of stuff commented out that should be cleaned up, but dismissing that, 
you should be able to get an idea of what was done to interface to the gpmc.

  The files I have is for the board (cape) I'm presently working with:

(4) sets of Servo PWM (PWM/DIR/Enable) outputs
(4) sets of Single ended Incremental Encoder inputs along with two inputs 
for limit switches
(1) Single Ended incremental Encoder input for Spindle
(1) PWM output for spindle speed control along with FWD,REV output 
commands, and a FLT input.
(1) Single Ended incremental encoder input for MPG (A and B only, no index 
input)
(1) UART in TTL mode to communicate with a uP on the MPG which encodes axis 
select and jog rate switches as well as other button inputs
Mist/flood output signals
E-stop signal chain
 
  To see a picture, go here:

http://xylotex.netfirms.com/OSCommerce/catalog/product_info.php?cPath=27_id=122

  Anyway, drop me an e-mail, and I'll try to get you the files you want.

Jeff



On Thursday, May 4, 2017 at 12:20:03 PM UTC-7, Timm Eversmeyer wrote:
>
>
>
> Am Dienstag, 2. Februar 2016 04:25:51 UTC+1 schrieb Jeff Pollard:
>>
>>
>>   I started with the TopEPPSHostMot2 version of the FPGA code from 
>> mesanet.com and modified that by removing the parallel port interface 
>> and building in the GPMC interface.  Then on the machinekit side I wrote a 
>> stand alone C program that did the same I/O as the hm2_Xi90.c file 
>> mentioned above.  There is a memory space in the FPGA where a "cookie" is 
>> stored once it has been properly programmed. The value is:55AACAFE and is 
>> stored at location 0x0100.  Once you can read that, you can start making 
>> your own hm2_XXX file.
>>
>>   Hopefully that will give people wanting to use hostmot2 with MachineKit 
>> a start on how I implemented it.
>>
>
> I have an unused LogiBone [1] which could be used to run hostmot2. I have 
> not found the VDHL code in your MachineKit fork [2]. Would you mind share 
> the GPMC adapter to hostmot2 with me?
>
> Your Beagle Bone FPGA shield looks nice. Looking forward to hear any news.
>
>
> [1] http://valentfx.com/logi-bone/  
> [2] 
> https://github.com/xylotex/MachineKit/tree/MachineKit-ubc/src/hal/drivers
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] MachineKit bindings

[Hedge Hog]

Thanks again Alex,
I'll look into those definitions.

Best wishes
Hedge

On Fri, May 5, 2017 at 6:03 AM, Alexander Rössler
 wrote:
>
>
> Am Dienstag, 2. Mai 2017 07:03:43 UTC-5 schrieb Hedge Hog:
>>
>> For those following along at home:
>>
>> With respect to:
>>
>> protobuf: it looks like the reference library in Ruby is Google's upb, see
>> [1], which is the encoder/decoder in MRI (see [2]) via Google's protobuf [3]
>
> Okay, good.
>
>>
>>
>> finite state machines: I did contemplate whether such an approach to a
>> 3D-printer would add value.  I'm still thinking.  But I'm inclined to the
>> view that if it does, then it won't be specific to Ruby and would be of
>> wider interest.  In which case using Ragel [4] to generate the FSM, and have
>> bindings to the c for various languages.
>
> The idea is to keep the FSM language independent which is reached by
> modeling the FSM in the SCXML format:
> https://github.com/machinekoder/machinetalk-gsl/blob/master/models/machinetalk/common/rpcclient_fsm.scxml
> You can choose any (or even none) underlying FSM library to work with.
>
>>
>> [1]: https://github.com/google/upb
>> [2]:
>> http://blog.reverberate.org/2015/05/status-update-on-upb-and-my-new-role-on.html
>> [3]: https://github.com/google/protobuf/tree/master/ruby
>> [4]: http://www.colm.net/open-source/ragel/
>>
>> On Monday, May 1, 2017 at 2:40:11 PM UTC+10, Alexander Rössler wrote:
>>>
>>> Depending on what you are trying to achieve there could also be other
>>> solutions to support Ruby. If you are looking for Ruby bindings to support
>>> Machinetalk then I recommend you to read up on this article:
>>> http://machinekoder.com/machinetalk-explained-part-5-code-generation/
>>>
>>> Here are the dependencies:
>>> http://zeromq.org/bindings:ruby
>>> https://github.com/ruby-protobuf/protobuf
>>> https://github.com/tenderlove/dnssd
>>> maybe: https://github.com/piotrmurach/finite_machine
>>>
>>> Create a basic working example -> create a code generator (probably
>>> similar to the python one) -> run the code generator -> implement the
>>> details
>>>
>>> Should give you working Machinetalk bindings pretty quickly.
>>>
>>> Am Freitag, 14. April 2017 19:16:25 UTC-5 schrieb Hedge Hog:

 Thanks for the prompt response Schooner...

 On Friday, April 14, 2017 at 11:05:12 PM UTC+10, Schooner wrote:
>
>
> On 14/04/17 13:05, Hedge Hog wrote:
>
 
>
> Unfortunately it seems that getting SWIG to consume the MK code base
> won't be trivial and _may_ require changes to the code to play nice with
> language bindings generated by SWIG. I'm new to swig. So, of course, I may
> just be revealing my ignorance and there are no changes required to the 
> base
> code :)
>
>
> There are already comprehensive python bindings and a lot of them are
> generated by cython as part of the build.
> That would be a place to start looking.
> There are additional python bindings specifically for machinetalk
> https://github.com/machinekit/pymachinetalk
>
 Thanks.  That is where I started as a way to identify the MK parts
 (currently) usefully publicized.

> You won't be able to just run a tool and magically generate bindings,
> the code is far too complex and interdependent.


 That is correct I don't think SWIG even suggests that.
 In fact a quick glance at SWIG 3.0 would persuade any bystander that
 there is no magic.

 I think there is an understanding that to be least painful your API
 would need to be written with the target languages _and_ SWIG in mind.
 That imposes some constraints in exchange for some benefits.
 Some projects (correctly) reject that compromise, saying it is up to the
 external libraries to make their syntax/idioms/semantics fit the parent
 project.
 I suppose I'm trying to gauge where MK community stand on these
 trade-offs.

 I would suggest that if anyone ever considered making an API change that
 taking into consideration the ability to support otherlanguage bindings
 might be a benefit to weigh against the costs of the change.

 The value-add proposition is that you could (MK code and external
 targets permitting) use SWIG to generate several bindings with little
 additional effort.
 Of course if some language forms a community large enough it is possible
 they will hand craft their own - but that takes a large community and we 
 are
 not there yet.

 

> I have no idea if there is an appetite for Ruby bindings, I have no use
> for the existing python ones so am not the person to ask :)
>
 Thanks again
 Best wishes
 Hedgehog
>
>
> The question becomes:
> Is there appetite in the project to support SWIG generated bindings
> (letting/encouraging each language's aficionados build what they want on 
> top
> of 

Re: [Machinekit] Machinekit messaging (machinetalk farbic)

[Alexander Rössler]

Am Dienstag, 2. Mai 2017 14:25:11 UTC-5 schrieb Hedge Hog:
>
> I preface this post with the acknowledgement that these areas are a 
> movable feast, and at some point you just have to ship something
> I also ack that I'm not 100% conversant with MK's use cases and 
> requirements.
>
> Nonetheless, I believe the following might be of interest.
>
> There are now several message formats that offer considerable speed 
> advantages over Protbuf.
>
So far speed has not been a problem with Protobuf. However, Flatbuffers 
look very interesting since the API and supported languages seems similar 
to Protobuf. On the other hand, Protobuf has a very wide adoption and is 
can also be used for storing data.

In fact I wonder if it isn't possible to simplify MK by replacing ZeroMQ 
> and Protobuf with something like Cap'n Proto, 
> Maybe ZeroMQ + Flatbuffers if the MK components are (as good as) stateless 
> and even SBE if random reads of messages is not required?  For what it is 
> worth I think the Flatbuffers note, see [3], that Cap'n Proto has "no 
> optional fields to allow deprecating fields or serializing with missing 
> fields for which defaults exist" might not be all it appears to be when you 
> review [1].  In my opinion, the feature comparison in [1] is more credible 
> than that at [3].
>
 Most of the other messaging middleware only support either RPC or 
publish-subscribe. Machinetalk services are stateless on the server side 
and stateful on the client side. The use of multi-channel protocols brings 
some additional advantages that we do not fully leverage yet. Such an 
advantage would be to use a multicast protocol for publishing status 
updates efficiently to multiple clients and at the same time having a 
reliable RPC connection to execute commands. The only attractive 
alternative to Machinetalk I have found so far is DDS. However, the 
middleware is covered by several software patents and encryption is only 
supported by closed-source solutions. 


> The issue seems to come down to how stateless/stateful are the different 
> components of MK.
>
> My naive understanding is that the important parts MK are stateful.  I 
> won't by surprised to find out that is naive - kinda like that moment you 
> were exposed to the dual representation in LP.
> Nonetheles I found these interesting, [1], [2].
>

> In particular [2] was interesting for the comment that, given their 
> targeted use cases it would make more sense to build ZeroMQ on Cap'n Proto 
> rather than pass Cap'n Proto messages around with ZeroMQ.
>
> I might have the wrong end of the stick here 
> Earlier I posted a comment that I wondered if driving and interacting with 
> a 3D-Printer or any CNC machine wouldn't be easier/best using a FSM (if 
> this was true Ragel was the suggested building block),
> If that idea isn't nuts, then I also wonder if ZeroMQ + Protobuf aren't 
> doing together what Cap'n Proto can do alone?
> Again I have little insight into how much method chaining there is between 
> MachineTalk mediated components, so the benefits may not outweigh the costs 
> of switching.
>
 Again, RPC won't cut it. Most of the interesting features of Machinetalk 
(such a synchronization between clients) are the result of using 
publish-subscribe to notify clients/subscribers instead of polling for 
status changes.


> Anyway, hope someone found these new or interesting
>
Yes, very interesting articles.
 

>
> [1] https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html
> [2] https://capnproto.org/faq.html
> [3] http://google.github.io/flatbuffers/md__benchmarks.html
>
> On Monday, May 1, 2017 at 2:33:35 PM UTC+10, Alexander Rössler wrote:
>>
>> I wrote a blog post about the design decisions behind Machinetalk some 
>> time ago:
>>
>> http://machinekoder.com/machinetalk-explained-part-2-middleware-requirements/
>>
>> ZeroMQ won the game because is was the best networking middleware choice 
>> for this application the time we started to work on Machinetalk.
>>
>> With Machinetalk GSL, Machinetalk also becomes transport agnostic. That 
>> makes things like WebVCP possible.
>>
>> Am Freitag, 14. April 2017 07:12:25 UTC-5 schrieb Hedge Hog:
>>>
>>> Thanks Schooner, I wasn't aware it was dead - unfortunate.
>>>
>>> On Friday, April 14, 2017 at 9:50:30 PM UTC+10, Schooner wrote:


 On 14/04/17 12:33, Hedge Hog wrote:

 Hi,
 I'm new to Machinekit, via the world of 3D Printing.  I'm new there 
 too, but doing my homework on 'best-practice' around boards and drivers 
 lead me here (via grbl, marlin, linuxcnc).

 I was very impressed you're using zeromq - my experience is that not 
 too many know about it outside of finance (at least that was true 7 years 
 ago).  
 It was that project choice that convinced someone here knows what they 
 are doing.

 Given that the use of ZeroMQ is in its early days in Machinekit I have 
 to ask:


 It has been used 

Re: [Machinekit] Re: MachineKit on BBB running Hostmot2 with Xilinx FPGA

['Timm Eversmeyer' via Machinekit]

Am Dienstag, 2. Februar 2016 04:25:51 UTC+1 schrieb Jeff Pollard:
>
>
>   I started with the TopEPPSHostMot2 version of the FPGA code from 
> mesanet.com and modified that by removing the parallel port interface and 
> building in the GPMC interface.  Then on the machinekit side I wrote a 
> stand alone C program that did the same I/O as the hm2_Xi90.c file 
> mentioned above.  There is a memory space in the FPGA where a "cookie" is 
> stored once it has been properly programmed. The value is:55AACAFE and is 
> stored at location 0x0100.  Once you can read that, you can start making 
> your own hm2_XXX file.
>
>   Hopefully that will give people wanting to use hostmot2 with MachineKit 
> a start on how I implemented it.
>

I have an unused LogiBone [1] which could be used to run hostmot2. I have 
not found the VDHL code in your MachineKit fork [2]. Would you mind share 
the GPMC adapter to hostmot2 with me?

Your Beagle Bone FPGA shield looks nice. Looking forward to hear any news.


[1] http://valentfx.com/logi-bone/  
[2] 
https://github.com/xylotex/MachineKit/tree/MachineKit-ubc/src/hal/drivers

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: protobuf/zeromq definition<->??<->HAL

[Alexander Rössler]

Hi Brian,

This is indeed a complex problem which Protobuf does not solve out of the 
box. This problem was one of the reasons why I started the Machinetalk GSL 
project. The protocol models describe to which Machinetalk message a 
Protobuf message belongs. 
https://github.com/machinekoder/machinetalk-gsl

There is also code generator for the documentation in the repository. The 
generated docs can be found 
here: https://github.com/machinekoder/machinetalk-doc

If you are more interested in this part of Machinetalk I recommend you to 
read http://machinekoder.com/machinetalk-explained-part-5-code-generation/

As for the messages in motcmds.proto -> most of the messages aren't in use 
by any service yet. Michael originally created them for the eventual 
replacement of NML by Machinetalk.

Best regards,
Alexander

Am Montag, 1. Mai 2017 12:22:47 UTC-5 schrieb Brian Schousek:
>
> I understand the motivation and appreciate the beauty of the messaging 
> approach. I seem to be missing something that is probably obvious in the 
> mechanics however. I can understand individual elements of 
> publish/subscribe, encode/decode, the anddemo at 
> https://github.com/machinekit/pymachinetalk makes sense to me, etc.
>
> I don't understand how to figure out how to initiate a channel containing 
> a given message. For example, I would like to monitor the messages as 
> defined in motcmds.proto 
> .
>  
> Are these message streams by definition flying around somewhere that I just 
> need to listen to? If so, where does it happen so I can look at the code 
> and further understand. Or perhaps these messages need to be turned on 
> somewhere? Or perhaps the messages are just defined here and it is left as 
> an exercise to the coder to generate them?
>
> In short, I feel like I understand the overarching intent, and also 
> understand much of the underlying detail, but I am not able to figure out 
> the connective tissue between the two. Would somebody please point me 
> towards enlightenment?
>
> Brian
>

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Config error for Probotix cape. 'PRU control files not found in /sys/class/uio/uio0'

[gburbeck]

Hi Charles

I say 'reloading' loosely - thanks for the clarification.

It's a custom configuration based on:

   - 
   - comet.hal
   - Designspark Novamill0.hal in the article - upgrading-a-cnc-machine
   - http://7xcnc.com/software/probing/z-touch-plate
   - 
   
https://forum.linuxcnc.org/forum/10-advanced-configuration/5596-manual-tool-change-tool-lengh-touch-off?start=30#48235
   
I've attached the key configuration files.

I'm happy to test a new setup.sh file.

Whilst it's irritating to have to start machinekit twice in order to get it 
working, it's not the end of the world.  

-- 
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.


MF70.hal
Description: Binary data


custom_postgui.hal
Description: Binary data


custompanel.xml
Description: XML document


MF70.ini
Description: Binary data

Re: [Machinekit] Machinekit Running Out of Memory Error Cramps + BBB

[schoone...@btinternet.com]

On 04/05/17 08:11, Peter wrote:

Hello,
i have a error i believe is related to axis preview and running out of 
memory. Any help would be gratefully appreciated on a solution. I have 
tried [User Command] Disable_Preview = Yes.

thank you in advance,
   Peter


The USER_COMMAND in your ini file will have the same effect as using 
(AXIS, hide) at the top of your gcode file

but try that as well
http://www.machinekit.io/docs/gui/axis/#axis-preview-control

Does it work with a smaller gcode file?

The bottom line unfortunately is that Axis was never intended for huge 
slicer generated gcode files for plastic squirting, whilst running on a 
very limited ARM board.
If you run tklinux or one of the non preview GUIs that should work, so 
will splitting your file down to manageable sections.

Or heaven forbid, using a proper computer:-P


--
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+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Machinekit Running Out of Memory Error Cramps + BBB

[Peter]

Hello,
i have a error i believe is related to axis preview and running out of 
memory. Any help would be gratefully appreciated on a solution. I have 
tried [User Command] Disable_Preview = Yes.
thank you in advance,
   Peter
the following is the error log output. for some reason i could not copy the 
kernel information but here is what i think is what is related and throwing 
errors.
/usr/bin/linuxcnc: line 816:  6201 Killed  $EMCDISPLAY -ini 
"$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
4870
  PID TTY  STAT   TIME COMMAND
6200
  PID TTY  STAT   TIME COMMAND
 6200 ?SL 0:20 milltask -ini 
/home/machinekit/machinekit/configs/CoreXYZ/CRAMPS.ini
  PID TTY  STAT   TIME COMMAND
 6200 ?SL 0:20 milltask -ini 
/home/machinekit/machinekit/configs/CoreXYZ/CRAMPS.ini
  PID TTY  STAT   TIME COMMAND
 6200 ?SL 0:20 milltask -ini 
/home/machinekit/machinekit/configs/CoreXYZ/CRAMPS.ini
  PID TTY  STAT   TIME COMMAND
 6200 ?SL 0:20 milltask -ini 
/home/machinekit/machinekit/configs/CoreXYZ/CRAMPS.ini
  PID TTY  STAT   TIME COMMAND
 6200 ?SL 0:20 milltask -ini 
/home/machinekit/machinekit/configs/CoreXYZ/CRAMPS.ini
  PID TTY  STAT   TIME COMMAND
 6200 ?SL 0:20 milltask -ini 
/home/machinekit/machinekit/configs/CoreXYZ/CRAMPS.ini
  PID TTY  STAT   TIME COMMAND
Stopping realtime threads
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
Unloading hal components
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri= 
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout

halcmd: the rtapi:0 RT demon is not running - please investigate 
/var/log/linuxcnc.log
[10112.148724] Out of memory: Kill process 4897 (rtapi:0) score 86 or 
sacrifice child
[10112.156938] Killed process 4897 (rtapi:0) total-vm:63832kB, 
anon-rss:48244kB, file-rss:10756kB












*Here is my ini file with the axis preview disable. I moved it around into 
different areas but currently it is near the beginning.*












[PRUCONF]
DRIVER=hal_pru_generic
CONFIG=pru=0 num_stepgens=4 num_pwmgens=6 pru_period=3500
PRUBIN=xenomai/pru_generic.bin


[EMC]

# Name of machine, for use with display, etc.
MACHINE =   MendelMax-CRAMPS

# Debug level, 0 means no messages. See src/emc/nml_int/emcglb.h for others
#DEBUG =0x0003
#DEBUG =0x0007
DEBUG = 0

[USER_COMMANDS]

DISABLE_PREVIEW = YES


[DISPLAY]

# Name of display program, e.g., tkemc
#DISPLAY = tkemc
#DISPLAY = gscreen
DISPLAY = axis

# Touchy currently won't work without some hardware buttons/jog-wheel
#DISPLAY = touchy

# Cycle time, in seconds, that display will sleep between polls
CYCLE_TIME =0.200

# Path to help file
HELP_FILE = tklinucnc.txt

Re: [Machinekit] Re: Cant use custom compiled kinematics - insmod error

[schoone...@btinternet.com]

On 04/05/2017 05:39, David Bynoe wrote:

Thank you so much for doing that! This is awesome.
I am not a programmer (but learning, slowly.) But I will play around 
with it, out of curiosity, what do you mean by problems with running 
actual gcode?

The config is just a sim of a conventional milling machine.

If you try to run the Machinekit demo for instance you will see:-)

You need to test within your actual machine configuration.

Good luck
The machine fortunately is rather robust, worse case scenario is the 
head whips around and I spend a few minutes untangling some string, 
which I am getting pretty good at.



On Tuesday, 2 May 2017 02:38:54 UTC-7, Schooner wrote:


On 02/05/17 10:10, schoo...@btinternet.com  wrote:


On 01/05/17 17:58, David Bynoe wrote:

Thank you for the tips, that relink solves the install problem
but it doesn't fix the insmod errors, I get the same ones as
before.

The kinematics file I want to use is this one:
https://github.com/dbynoe/Spark-Drawbot/blob/master/kinematics/drawbotkins.c




That version has automatic homing features and some other stuff
that will be removed but its known working on linuxcnc. It was
built for this machine:
https://www.youtube.com/watch?v=hrsDBdnj5E8


I am curious about what changed, I thought the whole point of
comp was that it allowed the building of hal components and
kinematics files outside of the source tree. Seems crazy that a
full rebuild/reinstall is necessary for one minor piece of
translation code.


comp has never been for compiling kinematics files outside the tree.
It is for building realtime modules from scripts requiring the
minimal C knowledge by the user.

It might be possible to build your file with comp, if you specify
the correct linkage, but you will notice that all the other
kinematic modules are
not built using it.

The kinematics file you are trying to use has no support for
vtables, that is at the heart of the problem and is what has
changed since it allegedly 'worked OK'
If you switch on debugging before launching and look at
/var/log/linuxcnc.log you will find the point of failure as (yes
I have built it)

*May  2 09:15:17 INTEL-i7 msgd:0: hal_lib:22291:rt
halg_reference_vtable:104 HAL error: vtable 'drawbotkins' version
1000 not found**
**May  2 09:15:17 INTEL-i7 msgd:0: hal_lib:22291:rt MOTION:
hal_reference_vtable(drawbotkins,1000) failed: -2*

You need to read
https://github.com/machinekit/machinekit/issues/438

and look at the changes made to kinematics.h and trivkins.c to
use vtables

I have built the drawbotkins module in the file tree and created
a demo sim for it as per the screenshot attached.

It is of general interest as it demonstrates the vtable code
required and for the amended kinematics module itself, so I will
get it included in the
repo kinematics code and it will be in the packages in a day or so.

regards


The PR is at https://github.com/machinekit/machinekit/pull/1205


You can see the code changes etc in that and watch it to see when
it is likely the new packages will be available (about 3 hours
after merge)

The sim is just to demo loading and homing, if you try to run
gcode you will get in all sorts of problems :-P
It would be good if you could provide a better sim in due course.



I have an older version of a machine kit image on a beaglebone
circa 2015 and comp just worked out of the box. Wanted to
modernize so I could use a touch screen and wifi. Here is it
running before:
https://www.youtube.com/watch?v=z0YQYwmbbT0




On Monday, 1 May 2017 07:03:13 UTC-7, Schooner wrote:


On 01/05/17 14:11, Marius Alksnys wrote:
> AFAIR I used this command:
> sudo ln -s /usr/lib/linuxcnc/xenomai /usr/lib/linuxcnc/posix
>
> After that comp installs components correctly.

That will get around the issue of posix flavour and give
somewhere to
install to and source from, certainly.;-)

There may well be an issue still with the kinematics linkage
as per the
previous message I quoted, that is
best dealt with by building within the source tree.

Give comp a try and see what happens, if you get an insmod
error that it
is unable to find vtable or similar
you are back to a source build

>
> 04/30/2017 09:48 PM, David Bynoe rašė:
>> I am having issues getting custom kinematics modules
compiled and
>> working on the debian jessie