Re: [Emc-users] A simple LinuxCNC system

[Gene Heskett]

On Wednesday 29 April 2020 01:10:54 John Dammeyer wrote:

> > If using the parport in EPP mode, you can set a reset time
> > separately, so you can step at the base thread rate. As far as motor
> > speed is concerned, the speed limit is generally the speed limit of
> > the opto stuff in the driver, and I've run steppeers laying on the
> > table at slightly better than 300 kilohertz with a 2M542 driver, or
> > about 3000 rpm. zero torque at that speed of course. :)
> >
> >
> > Cheers, Gene Heskett
>
> Hi Gene,
> I'm just in learn mode trying to figure out how LinuxCNC works.   Not
> worried about speed.  So far, with various steppers  when actually
> used to drive machines I've found that if you can step at 20kHz you
> are way beyond the torque capabilities of the motors. John
>
This is also true John, its the nature of the beasts. In fact one machine 
I own, a 6040 that came with crap electronics I had to replace all of, 
has a batch of the shortest nema 23 motors I have seen. But with a box 
of good drivers its doing rapids in the xy at 200 ipm.  The Z has to 
lift the horse or so spindle  motor so its all done at 35 ipm going up, 
but the little motors have much less inductance so they will take the 
needed currant at higher speeds where the 435's on the g0704 mill are 
all done well before 100 ipm.

Either. at working speeds has more than enough torque to shatter a 
plugged up with hot alu tool in a heartbeat. I very quickly found that 
mist cooling on that puppy was an absolute requirement so I invented 
some, I am pulsing a peristoltic pump, similar to what the hospitals use 
to put an IV drip in you. Pulse is settable from the axis gui.  Air for 
it is also switched by the same button.

I've also found that the proper programming of the vfd's can get enough 
power to cut alu at a quite decent feed rate even when that 24k revs 
spindle is only turning 1k revs, the secret is to set the low speed 
currant limits in the vfd to match the motors FLA rating. They don't 
come OOB set to do anything like that. Thats not always easy when trying 
to translate the vfd booklet, written in Chinglish, to something you and 
I might understand.  But I've done it twice now with amazing low speed 
results. My converted Sheldon lathe, with a 1 horse 3 phase that spent 
the first 40 years of its life on an air compressor, can pull large 
swarf turning blue, when driven at 8 hz, for long enough to get the job 
done, without getting the motor too hot to lay my hand on it. Flat, 
plumb, hasn't been used yet, don't need the backgear.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A simple LinuxCNC system

[andy pugh]

On Wed, 29 Apr 2020 at 01:35, John Dammeyer  wrote:

The important constants come from the INI file:
>

Note that they don't have to. A very simple LinuxCNC configuration can omit
the INI.
But once you loadrt motmod, then you need an INI to pass it the axis data.

  Is the real time component of Linux CNC running all the tasks that are
> started with the loadrt with a 24uS period?In other words all loaded
> "loadrt tasks" have to finish within 24uS or the system will start to have
> jitter or miss events.
>

No, only the functions that are addf-ed to the base-thread run at that
rate. Everything else (addf-ed to the servo-thread) runs at the
servo-thread rate.
This typically includes motion and the management section of many
components. So, for example, the stepgen has a servo-thread part that
calculates the step rate, and a base-thread portion that _only_ makes
steps.
Generally nothing in the base-thread does any floating-point calculations.
(base-thread FP used to be disallowed, in fact, but can now be turned on
via a switch)


> setp stepgen.0.steplen 1
> setp stepgen.0.stepspace 0
>
> Both values inside the motmod and parallel port tasks appear to set it to
> that value or the minimum BASE_PERIOD.  Whichever is shorter.  At least
> that is how I interpret it.
> Is that correct?

What that would mean is that although it wants a 1nS step length the
> reality is the minimum period is 24uS and since a step pulse is exactly
> that, a pulse, the step space is also 24uS.   So that implies the fastest
> step rate possible is 24uS ON and 24uS OFF or 48 uS minimum period which
> gives a 20.833kHz stepping rate.


In general yes, but the parallel port is a special case. It has a "reset"
function that can be configured to switch pins back to their default state
in the same thread cycle as the parport-write.
(The parport reset will actually busy-wait if the time has not yet elapsed,
so it is more efficient to put some other base-thread tasks between
parport-write and parport-reset in the base thread to avoid waiting, except
in cases where you need the parport pulses to be as short as possible
(which I can't think of a use-case for)

For a stepping motor driver with 10uStep per step that's still pretty well
> faster than it can actually turn.  For a Servo motor with a 2500 line
> encoder it's way too slow so a step multiplier or encoder divider would be
> required.
>

Step rate is not often a problem with the parport, encoder-counting hits
the limit a lot more often. Especially on spindles.

Now the trajectory planner.  Am I correct when I interpret that the
> trivkins planner runs at the BASE_PERIOD rate every 24 uS but uses the
> SERVO_PERIOD of 1mS (100nS) for trajectory updating.
>

No, everything bar the most basic pin-manipulation functions tends to run
at the servo-thread rate. (as you can see from typical HAL files)

But back to my final question for this post.  Is the Servo Period the time
> interval used to calculate the next motor velocity?
> So the acceleration is actually based on changing the velocity every 1mS
> for that 100nS SERVO_PERIOD value?


Yes. The acceleration and velocity  curves are all governed by a set of
_position_ waypoints that are updated every 1mS and sent straight to the
joint.N... HAL pins.

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

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Interesting ARM SOC for Machine Control

[Lester Caine]

On 29/04/2020 03:07, Bari wrote:


Has a FPGA interface and integrated ARM926 real-time core and tons of IO


It's a pity they decided to reinvent the 'banana-pi' footprint ... the 
one I have provides a nice sata port in the same footprint as a standard Pi

http://wiki.banana-pi.org/Banana_Pi_BPI-M1

But these new 'pi' devices don't follow the 'pi' format at all, some 
still retain the Raspberry Pi GPIO but it's not clear if an existing 
Raspberry Pi breakout board would actually fit? You will be better off 
with a new breakout board ...


For the observant ... what is wrong with the front and back image of the 
BPI-F2S ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Non-circular boring. Linuxcnc style.

[Stuart Stevenson]

Sam,
  I heard you say your circle is a polygon of a thousand sides.

In APT4 a circle of 2500 inches radius is calculated as a straight line.
That allows an algorithm for part profiles to be described as all radiuses
and the variable values determine the lines and circles.
Just another possibly interesting random detail out of the wet ram(thanks
Gene) brought out by a random comment.

Love your videos.

Stuart



On Tue, Apr 28, 2020 at 9:57 PM Sam Sokolik  wrote:

> just to see if it would...
>
> https://youtu.be/a7CO9gohaXE
>
>
>
> On Sun, Apr 26, 2020 at 2:54 PM Sam Sokolik  wrote:
>
> > the new encoder seems to work good :)
> >
> >
> >
> > On Tue, Apr 21, 2020 at 9:53 PM Jon Elson 
> wrote:
> >
> >> On 04/21/2020 09:11 PM, Sam Sokolik wrote:
> >> > Just the way the path was generated...  Didn't try that hard.  Acad ->
> >> ace
> >> > converter for simple stuff like this.  (Or by hand)
> >> >
> >> >
> >> I have a bunch of little C programs that write most of my
> >> G-code. Making round bores and rectangular pockets, and
> >> trepanning both of those shapes in sheet materials.  All of
> >> them do it by climb mill.
> >> Even when I did some things in bobcad, I set it up for climb
> >> mill.
> >>
> >> Try it sometime, you'll be surprised how much better it
> >> works - ESPECIALLY in aluminum.  Just program it to go
> >> counterclockwise around any internal pocket.
> >>
> >> Jon
> >>
> >>
> >> ___
> >> Emc-users mailing list
> >> Emc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-users
> >>
> >
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A simple LinuxCNC system

[Jon Elson]

On 04/29/2020 12:10 AM, John Dammeyer wrote:


Hi Gene,
I'm just in learn mode trying to figure out how LinuxCNC works.   Not worried 
about speed.  So far, with various steppers  when actually used to drive 
machines I've found that if you can step at 20kHz you are way beyond the torque 
capabilities of the motors.

Unless you are using drivers with microstepping, then you 
need more steps to get the same motor speed.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A simple LinuxCNC system

[Jon Elson]

On 04/29/2020 12:54 AM, John Dammeyer wrote:


Here's my question for you. If the asynchronous pulse 
generator from your $1 chip has just created a pulse and 
the SERVO_PERIOD now wants to a new rate how do you set up 
the frequency generator so that the next pulse is 
correctly spaced from the previous one? Or do you just 
hope it works out?
The trajectory planner uses a specified acceleration rate to 
change the commanded velocity in small increments.  Remember 
this is typically recomputed 1000 times a second.  So, there 
will not be huge jumps in commanded velocity.  Therefore, 
the change in time between steps will not be large, so the 
motor can follow it properly.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

>   Is the real time component of Linux CNC running all the tasks that are
> > started with the loadrt with a 24uS period?In other words all loaded
> > "loadrt tasks" have to finish within 24uS or the system will start to have
> > jitter or miss events.
> >
> 
> No, only the functions that are addf-ed to the base-thread run at that
> rate. Everything else (addf-ed to the servo-thread) runs at the
> servo-thread rate.
> This typically includes motion and the management section of many
> components. So, for example, the stepgen has a servo-thread part that
> calculates the step rate, and a base-thread portion that _only_ makes
> steps.
> Generally nothing in the base-thread does any floating-point calculations.
> (base-thread FP used to be disallowed, in fact, but can now be turned on
> via a switch)
> 
> 
> In general yes, but the parallel port is a special case. It has a "reset"
> function that can be configured to switch pins back to their default state
> in the same thread cycle as the parport-write.
> (The parport reset will actually busy-wait if the time has not yet elapsed,
> so it is more efficient to put some other base-thread tasks between
> parport-write and parport-reset in the base thread to avoid waiting, except
> in cases where you need the parport pulses to be as short as possible
> (which I can't think of a use-case for)

Thanks Andy,
A small lightbulb just went on.  The 

loadrt loadrt hal_parport cfg="0 out" 

just tells the OS that there is a function rtapi_app_main() that must be called 
to setup the list of functions that can be addf'd.

It's then the addf function names that must be exported in the rtapi_app_main() 
function.

The  
"addf functions _time_-thread"  
then add the functions to the real time OS task list running at BASE_PERIOD and 
they are added in the order they are in the HAL file. 

So below here:
==
# ESTOP and Charge Pump Support for safety
loadrt estop_latch
loadrt charge_pump

# Control of PWM for Spindle
addf pwmgen.make-pulses base-thread

# Monitor Parallel port inputs
addf parport.0.read base-thread

#Control of Parallel port step/dir/output signals
addf stepgen.make-pulses base-thread
addf parport.0.write base-thread

# make parallel port step pulses shorter than one base period
addf parport.0.reset base-thread
===

Having the parport-reset right after the parport-write means it sits in that 
while loop wasting time until the system clock in nano-seconds passes the set 
point of system clock + 5000 nanoseconds.

But if I move things around so there are more addf functions before the addf 
parport-reset I may find it doesn't spend any time in that do wait for timeout 
loop.
 
==
# Monitor Parallel port inputs
addf parport.0.read base-thread

#Control of Parallel port step/dir signals
addf stepgen.make-pulses base-thread
addf parport.0.write base-thread

# ESTOP and Charge Pump Support for safety
loadrt estop_latch
loadrt charge_pump

# Control of PWM for Spindle
addf pwmgen.make-pulses base-thread

# make parallel port step pulses shorter than one base period
addf parport.0.reset base-thread
===

John Dammeyer




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> >
> > Hi Gene,
> > I'm just in learn mode trying to figure out how LinuxCNC works.   Not 
> > worried about speed.  So far, with various steppers  when
> actually used to drive machines I've found that if you can step at 20kHz you 
> are way beyond the torque capabilities of the motors.
> >
> Unless you are using drivers with microstepping, then you
> need more steps to get the same motor speed.
> 
> Jon

Yes. Up until recently micro-stepper drives ran 10:1 but now they can do 256:1 
although the jury is out on whether anything past 10:1 is useful.  But that's a 
different discussion.

John



> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> From: Jon Elson [mailto:el...@pico-systems.com]
> On 04/29/2020 12:54 AM, John Dammeyer wrote:
> >
> > Here's my question for you. If the asynchronous pulse
> > generator from your $1 chip has just created a pulse and
> > the SERVO_PERIOD now wants to a new rate how do you set up
> > the frequency generator so that the next pulse is
> > correctly spaced from the previous one? Or do you just
> > hope it works out?
> The trajectory planner uses a specified acceleration rate to
> change the commanded velocity in small increments.  Remember
> this is typically recomputed 1000 times a second.  So, there
> will not be huge jumps in commanded velocity.  Therefore,
> the change in time between steps will not be large, so the
> motor can follow it properly.
> 
> Jon

Thanks Jon,
My ELS included most of that trajectory planning, step pulse generation and the 
LMD18245 micro-stepping control all inside what would be called the BASE_PERIOD 
thread in LinuxCNC.

That's because 14 years ago two LMD18245's and the associated parts cost less 
than any 3A 55V micro-stepping driver out there.  Now you can get that for the 
price of only one LMD18245 so that hardware is redundant.  Which means I've 
been rethinking how I'd do things.  

Interesting too how motion.c which I'm seeing for the first time is very 
similar to what I did in my ELS code.  I've ported the ELS from the PIC18F to a 
PIC32 and for the most part it's working.  And that interrupt routine that used 
to take about 35 microseconds now takes under 2 uS.And I want to run 
everything under the PIC32 version of FREE RTOS. 

John






___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] RXTX problem

[Gene Heskett]

This has nothing to do with linuxcnc other than this install is from one 
of our installers. 

I have a utility that talks to a 35 yo legacy computer, but needs the 
RXTX libraries to do it.

It hasn't worked since the old asus mobo burned up and was replaced with 
a newer, faster board and cpu also an Asus.

Several of these libraries including one I just installed, are here and 
there but it still won't load. I suspect its a path problem, but even 
dropping it into the same directory with the .jar that needs it isn't 
working.

I need a fresh idea. Anybody have a clue?

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RXTX problem

[Jon Elson]

On 04/29/2020 02:14 PM, Gene Heskett wrote:

This has nothing to do with linuxcnc other than this install is from one
of our installers.

I have a utility that talks to a 35 yo legacy computer, but needs the
RXTX libraries to do it.

Not familiar with this, is this a Java library?

It hasn't worked since the old asus mobo burned up and was replaced with
a newer, faster board and cpu also an Asus.

Well, what is the symptom?

Several of these libraries including one I just installed, are here and
there but it still won't load. I suspect its a path problem, but even
dropping it into the same directory with the .jar that needs it isn't
working.

Is there any diagnostic capability that can tell why "it 
won't load"?


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RXTX problem

[Gene Heskett]

On Wednesday 29 April 2020 15:52:58 Jon Elson wrote:

> On 04/29/2020 02:14 PM, Gene Heskett wrote:
> > This has nothing to do with linuxcnc other than this install is from
> > one of our installers.
> >
> > I have a utility that talks to a 35 yo legacy computer, but needs
> > the RXTX libraries to do it.
>
> Not familiar with this, is this a Java library?
>
> > It hasn't worked since the old asus mobo burned up and was replaced
> > with a newer, faster board and cpu also an Asus.
>
> Well, what is the symptom?
>
> > Several of these libraries including one I just installed, are here
> > and there but it still won't load. I suspect its a path problem, but
> > even dropping it into the same directory with the .jar that needs it
> > isn't working.
>
> Is there any diagnostic capability that can tell why "it
> won't load"?
>
> Jon
Just this, from a script I wrote many years ago:
gene@coyote:/CoCo$ ./dwstart
/CoCo/dw4directory
gene@coyote:/CoCo$ deleting old lockfile /var/lock/LCK..ttyUSB1
total 4
drwxr-xr-x 2 www-data root 40 Apr 29 14:23 apache2
-rw-r--r-- 1 root root 22 Apr 29 14:23 asound.state.lock
-rw-r--r-- 1 root root  0 Apr 29 14:23 ntpdate
drwx-- 2 root root 40 Apr 29 14:23 schroot
drwxr-xr-x 2 root root 40 Apr 29 14:23 subsys
-rw-rw-rw- 1 root root  0 Apr 29 14:24 tdekbdledsync-:0.lock
total 4
drwxr-xr-x 2 www-data root 40 Apr 29 14:23 apache2
-rw-r--r-- 1 root root 22 Apr 29 14:23 asound.state.lock
-rw-r--r-- 1 root root  0 Apr 29 14:23 ntpdate
drwx-- 2 root root 40 Apr 29 14:23 schroot
drwxr-xr-x 2 root root 40 Apr 29 14:23 subsys
-rw-rw-rw- 1 root root  0 Apr 29 14:24 tdekbdledsync-:0.lock
29 Apr 2020 15:57:04 INFO  [dwserver-10   ] DriveWire Server v4.3.3o 
starting
FATAL: UseRXTX is set, but RXTX native libraries could not be loaded
Yikes!

java.lang.ExceptionInInitializerError
at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
at org.eclipse.swt.widgets.Display.(Unknown Source)
at com.groupunix.drivewireui.MainWin.main(MainWin.java:374)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.swtjar.SWTLoader.main(SWTLoader.java:47)
Caused by: java.lang.NullPointerException
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1847)
at java.lang.Runtime.loadLibrary0(Runtime.java:871)
at java.lang.System.loadLibrary(System.java:1124)
at org.eclipse.swt.internal.Library.load(Unknown Source)
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.C.(Unknown Source)
... 9 more

FATAL: Please see 
http://sourceforge.net/apps/mediawiki/drivewireserver/index.php?title=Installation

And the last link no longer exists. Somebody has redone about 75% of it 
in python, but zero installation tuts there either.  So I'm flying 
blind.
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RXTX problem

[Brent Loschen]

I've used jssc, 
 the successor 
to RXTX, with much success.  It's multi platform and open source.  Never 
had much luck with RXTX.


On 4/29/2020 1:14 PM, Gene Heskett wrote:

This has nothing to do with linuxcnc other than this install is from one
of our installers.

I have a utility that talks to a 35 yo legacy computer, but needs the
RXTX libraries to do it.

It hasn't worked since the old asus mobo burned up and was replaced with
a newer, faster board and cpu also an Asus.

Several of these libraries including one I just installed, are here and
there but it still won't load. I suspect its a path problem, but even
dropping it into the same directory with the .jar that needs it isn't
working.

I need a fresh idea. Anybody have a clue?

Thanks.

Cheers, Gene Heskett



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] 6i24 + 7i44 + 7i52s + 7i33 is it possible?

[Leonardo Marsaglia]

Solved. I just had to increase the step length and step space to at least
1000 nsec because the vfd would work with pulses shorter than that. So, for
now I don't need to plug the 7i33.

El mar., 28 abr. 2020 a las 20:15, Leonardo Marsaglia (<
ldmarsag...@gmail.com>) escribió:

> By the way, this is the firmware I'm using now that Peter genly made for
> me. I needed it with a special arrangement for the 7i44 because of the way
> I'm mounting the boards.
>
> http://freeby.mesanet.com/5i24_25r.zip
>
> El mar., 28 abr. 2020 a las 20:13, Leonardo Marsaglia (<
> ldmarsag...@gmail.com>) escribió:
>
>> Hello guys,
>>
>> This will be probably for Peter but may be some of you have a similar
>> configuration.
>>
>> I'm having a little bit of trouble trying to drive my spindle VFD with a
>> step generator. I have an unused slot on the 6i24 and I have a 7i33 that
>> I'm not using. Could it be possible to write a firmware to use the 7i33 in
>> combination with the other two daughter cards (7i52s + 7i44)?
>>
>> I had the VFD working with analog voltage before this conversion so I can
>> stick to that config and I only would need to replace the firmware and plug
>> another board.
>>
>> Thanks!
>>
>> Leonardo
>>
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] More camshaft turning/external offsets

[Leonardo Marsaglia]

I installed another tool holder with much more relief and now I can rough
the lobes in one pass. Here's a video of a one pass rough cut. I'm turning
the spindle at about 100 RPM and the depth of the cut is 3.5 mm
approximately.

Here's the video: https://youtu.be/xjBXa6RHSPQ

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RXTX problem

[Gene Heskett]

On Wednesday 29 April 2020 16:05:11 Brent Loschen wrote:

> I've used jssc,
>  the
> successor to RXTX, with much success.  It's multi platform and open
> source.  Never had much luck with RXTX.
>
But how do I convince the .jar that wants RXTX, that jssc is the same 
flavor its looking for.

Thanks.

> On 4/29/2020 1:14 PM, Gene Heskett wrote:
> > This has nothing to do with linuxcnc other than this install is from
> > one of our installers.
> >
> > I have a utility that talks to a 35 yo legacy computer, but needs
> > the RXTX libraries to do it.
> >
> > It hasn't worked since the old asus mobo burned up and was replaced
> > with a newer, faster board and cpu also an Asus.
> >
> > Several of these libraries including one I just installed, are here
> > and there but it still won't load. I suspect its a path problem, but
> > even dropping it into the same directory with the .jar that needs it
> > isn't working.
> >
> > I need a fresh idea. Anybody have a clue?
> >
> > Thanks.
> >
> > Cheers, Gene Heskett
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More camshaft turning/external offsets

[John Dammeyer]

> -Original Message-
> From: Leonardo Marsaglia [mailto:ldmarsag...@gmail.com]
> Sent: April-29-20 2:49 PM
> To: Enhanced Machine Controller (EMC)
> Subject: [Emc-users] More camshaft turning/external offsets
> 
> I installed another tool holder with much more relief and now I can rough
> the lobes in one pass. Here's a video of a one pass rough cut. I'm turning
> the spindle at about 100 RPM and the depth of the cut is 3.5 mm
> approximately.
> 
> Here's the video: https://youtu.be/xjBXa6RHSPQ
> 

Nice.  Cast iron cam shaft?  Does it get hardened after?  If so how?
John

> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] More camshaft turning/external offsets

[Leonardo Marsaglia]

Hello John,

Indeed, nodular/ductile cast iron. We harden the cams with induction
heating, controlled by LCNC too off course. After that we grind them to the
final dimensions.



El mié., 29 abr. 2020 a las 19:03, John Dammeyer ()
escribió:

>
>
> > -Original Message-
> > From: Leonardo Marsaglia [mailto:ldmarsag...@gmail.com]
> > Sent: April-29-20 2:49 PM
> > To: Enhanced Machine Controller (EMC)
> > Subject: [Emc-users] More camshaft turning/external offsets
> >
> > I installed another tool holder with much more relief and now I can rough
> > the lobes in one pass. Here's a video of a one pass rough cut. I'm
> turning
> > the spindle at about 100 RPM and the depth of the cut is 3.5 mm
> > approximately.
> >
> > Here's the video: https://youtu.be/xjBXa6RHSPQ
> >
>
> Nice.  Cast iron cam shaft?  Does it get hardened after?  If so how?
> John
>
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] G96 and spindle override on axis not working

[Leonardo Marsaglia]

It's me again,

We managed to get the spindle VFD working with pulse input command. The
problem is, I can't get to work the G96 code or the feed override on axis.
I'm able to set different speeds via MDI and it responds well but that's
all. The feed override slider is behaving like a on/off switch turning off
the spindle when it reaches to zero. Also, If I increase the speed using
the buttons on manual mode on axis the RPMs jump in a very staggered way.
In MDI this doesn't happen.

Checking the *spindle.M.speed−in* it seems to receive the RPS from the
encoder module. The only thing that's not looking good is how noisy the
signal is. I didn't activate the encoder filter but I can try that
tomorrow, although I don't think that's what's avoiding G96 to work.

I tried the same g-code on axis sim lathe and it works ok. Any ideas? I
suspect it's the same thing that's causing both problems but I don't know
where to look. Please let me know what you think.

Thank you as always!

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G96 and spindle override on axis not working

[Gene Heskett]

On Wednesday 29 April 2020 19:02:17 Leonardo Marsaglia wrote:

> It's me again,
>
> We managed to get the spindle VFD working with pulse input command.
> The problem is, I can't get to work the G96 code or the feed override
> on axis. I'm able to set different speeds via MDI and it responds well
> but that's all. The feed override slider is behaving like a on/off
> switch turning off the spindle when it reaches to zero. Also, If I
> increase the speed using the buttons on manual mode on axis the RPMs
> jump in a very staggered way. In MDI this doesn't happen.
>
> Checking the *spindle.M.speed−in* it seems to receive the RPS from the
> encoder module. The only thing that's not looking good is how noisy
> the signal is. I didn't activate the encoder filter but I can try that
> tomorrow, although I don't think that's what's avoiding G96 to work.
>
> I tried the same g-code on axis sim lathe and it works ok. Any ideas?
> I suspect it's the same thing that's causing both problems but I don't
> know where to look. Please let me know what you think.
>
> Thank you as always!

If the pwmgen you are using has a "PDM" mode, try that along with 
reducing the frequency. A kilohertz s/b plenty.  The vfd will average it 
nicely, and the lower frequency will give more, different speeds.  In 
PDM mode and low speeds it will skip pulses, or should.
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G96 and spindle override on axis not working

[Leonardo Marsaglia]

Hello Gene,

I'm using a step generator from the 7i52 to feed the pulse command input on
the Yaskawa v1000. So I have to play with the scale factor to modify the
frequency. The driver accepts a maximum frequency of 32 khz and it has a
max freq setting inside that range to set up the maximum velocity. I'll try
to play with that tomorrow.

What I don't understand is why I don't have a ramping velocity when using
G96 for grooving for example. May be I'm clipping onto max rpm when I set
up the cam software? Because I'm limiting the RPMs for the grooves to 700
RPM max no matter the surface speed. Needless to say, I'm still getting
myself used to make my programs with CAM software.

But there's still the feed override problem on axis, wich is not a big
concern because I'm not planning to override the spindle from that slider,
but It worries me that it's not working like it should be.

Thanks!



El mié., 29 abr. 2020 a las 21:10, Gene Heskett ()
escribió:

> On Wednesday 29 April 2020 19:02:17 Leonardo Marsaglia wrote:
>
> > It's me again,
> >
> > We managed to get the spindle VFD working with pulse input command.
> > The problem is, I can't get to work the G96 code or the feed override
> > on axis. I'm able to set different speeds via MDI and it responds well
> > but that's all. The feed override slider is behaving like a on/off
> > switch turning off the spindle when it reaches to zero. Also, If I
> > increase the speed using the buttons on manual mode on axis the RPMs
> > jump in a very staggered way. In MDI this doesn't happen.
> >
> > Checking the *spindle.M.speed−in* it seems to receive the RPS from the
> > encoder module. The only thing that's not looking good is how noisy
> > the signal is. I didn't activate the encoder filter but I can try that
> > tomorrow, although I don't think that's what's avoiding G96 to work.
> >
> > I tried the same g-code on axis sim lathe and it works ok. Any ideas?
> > I suspect it's the same thing that's causing both problems but I don't
> > know where to look. Please let me know what you think.
> >
> > Thank you as always!
>
> If the pwmgen you are using has a "PDM" mode, try that along with
> reducing the frequency. A kilohertz s/b plenty.  The vfd will average it
> nicely, and the lower frequency will give more, different speeds.  In
> PDM mode and low speeds it will skip pulses, or should.
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] RXTX problem

[Brent Loschen]

On 4/29/2020 3:52 PM, Gene Heskett wrote:

On Wednesday 29 April 2020 16:05:11 Brent Loschen wrote:


I've used jssc,
 the
successor to RXTX, with much success.  It's multi platform and open
source.  Never had much luck with RXTX.


But how do I convince the .jar that wants RXTX, that jssc is the same
flavor its looking for.

Thanks.
The api's for RXTX are different than those for jssc, so it's not a drop 
in replacement.   In the Java world, the jssc library is considered 
superior to the ancient Java wrapper library for RXTX native code, but 
to use it would require changes to the Java source code for your 
application (your .jar file).  Apologies if I misunderstood your 
original request.


If it's potentially a configuration problem, this documentation 
may help you 
determine if the RXTX components are in the right locations relative to 
your Java installation.


What does the Java application do?  Do you have the source code for it?  
If so, I'd be happy to take a crack at changing it to utilize jssc.





On 4/29/2020 1:14 PM, Gene Heskett wrote:

This has nothing to do with linuxcnc other than this install is from
one of our installers.

I have a utility that talks to a 35 yo legacy computer, but needs
the RXTX libraries to do it.

It hasn't worked since the old asus mobo burned up and was replaced
with a newer, faster board and cpu also an Asus.

Several of these libraries including one I just installed, are here
and there but it still won't load. I suspect its a path problem, but
even dropping it into the same directory with the .jar that needs it
isn't working.

I need a fresh idea. Anybody have a clue?

Thanks.

Cheers, Gene Heskett

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Interesting ARM SOC for Machine Control

[Przemek Klosowski]

On Wed, Apr 29, 2020 at 5:05 AM Lester Caine  wrote:

> For the observant ... what is wrong with the front and back image of the
> BPI-F2S ...
>
> OK I give up---what's  wrong? I assume you're talking about
http://wiki.banana-pi.org/images/a/a6/850x371xBanana_PI_BPI-F2S_6.JPG.pagespeed.ic.6JAnstxchO.webp

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users