[Machinekit] Joint 5 follow error for XYZAC machine

['Ryan Perez' via Machinekit]

Hello,
I am designing a 5-axis machine with a XYZAC orientation. I can currently 
control/send commands to XYZA steppers but am having trouble with the C 
axis of rotation. I get a joint 5 following error every time I try to 
control the C rotation. the specific error in the command line is:
 
emc/task/taskintf.cc 617: Error on axis 5, command number 141

The C axis setup is identical to the A axis so I am struggling to find out 
where the error is being triggered. I am using trivkins. Any help would be 
great!

Here are the ini sections connected to the C axis

[TRAJ]
COORDINATES = X Y Z A C
AXES = 6
JOINTS = 5
MAX_ANGULAR_VELOCITY = 45.00
DEFAULT_ANGULAR_VELOCITY = 4.50
LINEAR_UNITS = mm
ANGULAR_UNITS = degree
CYCLE_TIME = 0.010
DEFAULT_VELOCITY = 5.0
MAX_LINEAR VELOCITY = 10.0
NO_FORCE_HOMING = 0

[AXIS_5]
TYPE = ANGULAR
MAX_VELOCITY = 31.89
MAX_ACCELERATION = 3000.0
STEPGEN_MAX_VEL = 37.0
STEPGEN_MAXACCEL = 3750.0
BACKLASH = 0.0
SCALE = -744.53
MIN_LIMIT = -.0
MAX_LIMIT = .0
FERROR = 1.0
MIN_FERROR = 0.25
HOME = 0.0
HOME_OFFSET = 0.0

and the hal section

#C-axis
setp hpg.stepgen.04.position-scale [AXIS_5]SCALE
setp hpg.stepgen.04.steplen 2000
setp hpg.stepgen.04.stepspace 2000
setp hpg.stepgen.04.dirhold 35000
setp hpg.stepgen.04.dirsetup 3500
setp hpg.stepgen.04.maxaccel [AXIS_5]STEPGEN_MAXACCEL
net cpos-cmd axis.4.motor-pos-cmd => hpg.stepgen.04.position-cmd
net cpos-fb hpg.stepgen.04.position-fb => axis.4.motor-pos-fb
net cenable axis.4.amp-enable-out => hpg.stepgen.04.enable

setp hpg.stepgen.04.steppin 929
setp hpg.stepgen.04.dirpin  931

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/44d65ac8-75b8-42ee-bb60-209c8b9dbe69%40googlegroups.com.

[Machinekit] Pru Driver conflict with gpio

[Sergio Alejandro Salinas]

I hope you are doing well, I have been working in this problem some time 
now.

So, I am using *LinuxCNC/Machinekit* in a *Beaglebone* with a *Probotix 
PBX-BB rev 5.2*. I am trying to use *three *axis, with its *dir *and *step *
signal.

At first I had the problem that the motor was moving in* one direction* 
only. This was solved by* removing the pins* used (812, 813, 814, 815) from 
the line from the .hal

loadrt hal_bb_gpio output_pins=816,818,819 input_pins=807,808,809,810,817
(so it was a pin conflict between both drivers, the gpio and the pru)

If I *add *the pins (812, 813, 814, 815) to the previous line, it moves in 
one direction, then if I edit the file to remove then, it moves as desired, 
but when rebooting, it stops working, and I need to do the previous steps 
(add and remove the pins).

I think the hal_bb_gpio is copying the configuration file to a directory 
the pru driver is not able to do alone, as consequence of how I have the 
configuration.


I attached my .hal .ini .bbio, and setup.h (until now, I have been working 
over the CRAMPS files).


What are your thoughts?


Thanks in advance


Sergio Salinas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/b210f32a-92e3-4aef-81f4-7cae8fa9365e%40googlegroups.com.


CRAMPS.ini
Description: Binary data


CRAMPS.hal
Description: Binary data
#!/bin/bash
# Copyright 2013
# Charles Steinkuehler 
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

dtbo_err () {
	echo "Error loading device tree overlay file: $DTBO" >&2
	exit 1
}

pin_err () {
	echo "Error exporting pin:$PIN" >&2
	exit 1
}

dir_err () {
	echo "Error setting direction:$DIR on pin:$PIN" >&2
	exit 1
}

PRU=/sys/class/uio/uio0
echo -n "Waiting for $PRU "

while [ ! -r $PRU ]
do
echo -n "."
sleep 1
done
echo OK

if [ ! -r $PRU ] ; then
	echo PRU control files not found in $PRU >&2
	exit 1;
fi

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

On Tue, 18 Feb 2020, 11.39 Michael Brown  wrote:

> BTW the newest de10 SD images are around here:
> https://github.com/the-snowwhite/soc-image-buildscripts
>
>>
>> Look for binary releases

Sorry for the messy mails but I'm currently in hospital attempting to get
thru via my phone...

>
>>
On Tue, 18 Feb 2020, 11.26 Michael Brown  wrote:
>
>> It's unfortunately not as simple as the frame buffer is hardwired to the
>> display parameters in quartus. Resolution change requires changing the FB
>> parameters in quartus... Generating a new bit file and then generating an
>> altered device tree with the new display parameters.
>> Michael B.
>>
>> On Tue, 18 Feb 2020, 01.22 justin White  wrote:
>>
>>> I know I've seen some resolution numbers in the quartus files so I
>>> assumed this was using part of the FPGA to do a framebuffer or something
>>> and it was actually part of the Quartus project. I thought the BBB actually
>>> had a GPU unlike the nano. I'll definitely try it when I get a chance, the
>>> 800x480 monitor looks like trash, even being small.hoping to pick up
>>> and get this going on a 1024x600 version.
>>>
>>> I believe the de10-nano image here is the one I used
>>> https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
>>>
>>>
>>>
>>> On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler
>>> wrote:

 I don't currently have a DE10-Nano running, but I reviewed the code and
 it looks like you should be able to set the resolution the same as you
 would for any other embedded display (by passing some kernel
 parameters).  Refer to:

 * The modedb documentation:

 https://www.kernel.org/doc/Documentation/fb/modedb.txt

 * My posts on setting resolutions on the BBB:


 http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html

 http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html

 I think you just need an entry similar to the following in your kernel
 command line:

video=800x480M@60

 Are you using an available uSD card image?  If so, I can pop it into my
 DE10 and try to get it working with one of my small HDMI based LCD
 screens if the above doesn't work for you.

 On 2/16/2020 7:46 PM, justin White wrote:
 > Been away from this project for a short bit but I had a pretty good
 use
 > come up for it recently. Main thing I'm having a problem with is the
 FB
 > resolution that was configured, 1024x768 is a dead resolution. Only
 old
 > monitors natively support it and nothing with HDMI does. Larger HDMI
 > monitors can handle it but nothing in the 7-9" range can display it
 through
 > HDMI. That's unfortunate because the main reason for FB use with this
 thing
 > is for an HMI all in one type device. Is there any chance more
 monitor
 > resolutions can be supported?
 >
 > I asked this before and MB responded, but unfortunately this is over
 my head
 >
 >> OK back to being able to be online with my workstation:
 >> I have allways had a fight setting up proper display resolutions on
 the
 >> altera soc's however I can give you some key notes:
 >> In qsys there are 3 cores to consider:
 >> For display timing settings:
 >> alt_vip_vfr_hdmi (framereader)
 >>
 >> alt_vip_itc_0 (Clocked video output)
 >>
 >> The display core clock itself:
 >> pll_lcd --> lcd_clk
 >>
 >>
 >> 1600x900 would allow me to test it out on my mill and I might have a
 use
 >>> for 800x480. I didn't realize the resolution was fixed, my 1080P
 monitors
 >>> don't have a problem displaying 1024x768, all my other monitors do.
 I
 >>> suppose in a real usage scenario I'd have to look further into your
 >>> previous reply and try to figure out how to set a resolution for
 whatever
 >>> monitor I intended to use.
 >>
 >>
 >> Sadly there are currently no presets for these 2 resolutions for the
 >> framebuffer related cores (presets are found in qsys view menu), as
 I
 >> havent had use of these resolutions m...
>>>
>>> --
>>> website: http://www.machinekit.io blog: http://blog.machinekit.io
>>> github: https://github.com/machinekit
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Machinekit" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> machinekit+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/machinekit/ad920189-10a0-4850-82f8-4436d5c20364%40googlegroups.com
>>> 
>>> .
>>>
>>

-

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

BTW the newest de10 SD images are around here:
https://github.com/the-snowwhite/soc-image-buildscripts

On Tue, 18 Feb 2020, 11.26 Michael Brown  wrote:

> It's unfortunately not as simple as the frame buffer is hardwired to the
> display parameters in quartus. Resolution change requires changing the FB
> parameters in quartus... Generating a new bit file and then generating an
> altered device tree with the new display parameters.
> Michael B.
>
> On Tue, 18 Feb 2020, 01.22 justin White  wrote:
>
>> I know I've seen some resolution numbers in the quartus files so I
>> assumed this was using part of the FPGA to do a framebuffer or something
>> and it was actually part of the Quartus project. I thought the BBB actually
>> had a GPU unlike the nano. I'll definitely try it when I get a chance, the
>> 800x480 monitor looks like trash, even being small.hoping to pick up
>> and get this going on a 1024x600 version.
>>
>> I believe the de10-nano image here is the one I used
>> https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
>>
>>
>>
>> On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler
>> wrote:
>>>
>>> I don't currently have a DE10-Nano running, but I reviewed the code and
>>> it looks like you should be able to set the resolution the same as you
>>> would for any other embedded display (by passing some kernel
>>> parameters).  Refer to:
>>>
>>> * The modedb documentation:
>>>
>>> https://www.kernel.org/doc/Documentation/fb/modedb.txt
>>>
>>> * My posts on setting resolutions on the BBB:
>>>
>>>
>>> http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html
>>>
>>> http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html
>>>
>>> I think you just need an entry similar to the following in your kernel
>>> command line:
>>>
>>>video=800x480M@60
>>>
>>> Are you using an available uSD card image?  If so, I can pop it into my
>>> DE10 and try to get it working with one of my small HDMI based LCD
>>> screens if the above doesn't work for you.
>>>
>>> On 2/16/2020 7:46 PM, justin White wrote:
>>> > Been away from this project for a short bit but I had a pretty good
>>> use
>>> > come up for it recently. Main thing I'm having a problem with is the
>>> FB
>>> > resolution that was configured, 1024x768 is a dead resolution. Only
>>> old
>>> > monitors natively support it and nothing with HDMI does. Larger HDMI
>>> > monitors can handle it but nothing in the 7-9" range can display it
>>> through
>>> > HDMI. That's unfortunate because the main reason for FB use with this
>>> thing
>>> > is for an HMI all in one type device. Is there any chance more monitor
>>> > resolutions can be supported?
>>> >
>>> > I asked this before and MB responded, but unfortunately this is over
>>> my head
>>> >
>>> >> OK back to being able to be online with my workstation:
>>> >> I have allways had a fight setting up proper display resolutions on
>>> the
>>> >> altera soc's however I can give you some key notes:
>>> >> In qsys there are 3 cores to consider:
>>> >> For display timing settings:
>>> >> alt_vip_vfr_hdmi (framereader)
>>> >>
>>> >> alt_vip_itc_0 (Clocked video output)
>>> >>
>>> >> The display core clock itself:
>>> >> pll_lcd --> lcd_clk
>>> >>
>>> >>
>>> >> 1600x900 would allow me to test it out on my mill and I might have a
>>> use
>>> >>> for 800x480. I didn't realize the resolution was fixed, my 1080P
>>> monitors
>>> >>> don't have a problem displaying 1024x768, all my other monitors do.
>>> I
>>> >>> suppose in a real usage scenario I'd have to look further into your
>>> >>> previous reply and try to figure out how to set a resolution for
>>> whatever
>>> >>> monitor I intended to use.
>>> >>
>>> >>
>>> >> Sadly there are currently no presets for these 2 resolutions for the
>>> >> framebuffer related cores (presets are found in qsys view menu), as I
>>> >> havent had use of these resolutions m...
>>
>> --
>> website: http://www.machinekit.io blog: http://blog.machinekit.io
>> github: https://github.com/machinekit
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Machinekit" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> machinekit+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/machinekit/ad920189-10a0-4850-82f8-4436d5c20364%40googlegroups.com
>> 
>> .
>>
>

-- 
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

Re: [Machinekit] Re: DE10 Nano suggested development environment?

[Michael Brown]

It's unfortunately not as simple as the frame buffer is hardwired to the
display parameters in quartus. Resolution change requires changing the FB
parameters in quartus... Generating a new bit file and then generating an
altered device tree with the new display parameters.
Michael B.

On Tue, 18 Feb 2020, 01.22 justin White  wrote:

> I know I've seen some resolution numbers in the quartus files so I assumed
> this was using part of the FPGA to do a framebuffer or something and it was
> actually part of the Quartus project. I thought the BBB actually had a GPU
> unlike the nano. I'll definitely try it when I get a chance, the 800x480
> monitor looks like trash, even being small.hoping to pick up and get
> this going on a 1024x600 version.
>
> I believe the de10-nano image here is the one I used
> https://drive.google.com/drive/folders/1THXnrnt-v7iNownBqmdOQrJ-i8EVAsSZ
>
>
>
> On Monday, February 17, 2020 at 5:34:07 PM UTC-5, Charles Steinkuehler
> wrote:
>>
>> I don't currently have a DE10-Nano running, but I reviewed the code and
>> it looks like you should be able to set the resolution the same as you
>> would for any other embedded display (by passing some kernel
>> parameters).  Refer to:
>>
>> * The modedb documentation:
>>
>> https://www.kernel.org/doc/Documentation/fb/modedb.txt
>>
>> * My posts on setting resolutions on the BBB:
>>
>>
>> http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html
>>
>> http://blog.machinekit.io/2013/07/custom-hdmi-resolution.html
>>
>> I think you just need an entry similar to the following in your kernel
>> command line:
>>
>>video=800x480M@60
>>
>> Are you using an available uSD card image?  If so, I can pop it into my
>> DE10 and try to get it working with one of my small HDMI based LCD
>> screens if the above doesn't work for you.
>>
>> On 2/16/2020 7:46 PM, justin White wrote:
>> > Been away from this project for a short bit but I had a pretty good use
>> > come up for it recently. Main thing I'm having a problem with is the FB
>> > resolution that was configured, 1024x768 is a dead resolution. Only old
>> > monitors natively support it and nothing with HDMI does. Larger HDMI
>> > monitors can handle it but nothing in the 7-9" range can display it
>> through
>> > HDMI. That's unfortunate because the main reason for FB use with this
>> thing
>> > is for an HMI all in one type device. Is there any chance more monitor
>> > resolutions can be supported?
>> >
>> > I asked this before and MB responded, but unfortunately this is over my
>> head
>> >
>> >> OK back to being able to be online with my workstation:
>> >> I have allways had a fight setting up proper display resolutions on
>> the
>> >> altera soc's however I can give you some key notes:
>> >> In qsys there are 3 cores to consider:
>> >> For display timing settings:
>> >> alt_vip_vfr_hdmi (framereader)
>> >>
>> >> alt_vip_itc_0 (Clocked video output)
>> >>
>> >> The display core clock itself:
>> >> pll_lcd --> lcd_clk
>> >>
>> >>
>> >> 1600x900 would allow me to test it out on my mill and I might have a
>> use
>> >>> for 800x480. I didn't realize the resolution was fixed, my 1080P
>> monitors
>> >>> don't have a problem displaying 1024x768, all my other monitors do. I
>> >>> suppose in a real usage scenario I'd have to look further into your
>> >>> previous reply and try to figure out how to set a resolution for
>> whatever
>> >>> monitor I intended to use.
>> >>
>> >>
>> >> Sadly there are currently no presets for these 2 resolutions for the
>> >> framebuffer related cores (presets are found in qsys view menu), as I
>> >> havent had use of these resolutions m...
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Machinekit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/machinekit/eVhvTnuhblE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/ad920189-10a0-4850-82f8-4436d5c20364%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CAGKWNWOqfEdkwJZW%3DMgACBt-K%2B_eubXt_2EKsH00dEyTenHmxw%40mail.gmail.com.