Hi All:
I'm now the happy owner of a beautiful Bridgeport Series I BOSS 5.
Nuthin like the 68000 as your main processor. I was scanning the
archive for ports to my machine, and I can't find any. I don't suppose
I just missed it? Or will I need to port EMC to my machine myself?
Does anybody
Sebastian,
The code I patched was checked out on Wednesday, and consisted of the
following at about lines 103 and 104 in stepgen.c:
if (s->hal.param.maxvel > fabs(max_pos_per_s)
s->hal.param.maxvel = fabs(max_pos_per_s);
Regards,
Eric
> The run-away problem seems to be licked, at least for r
You can only *properly* diagnose PWM signal with an oscilloscope or a
digital analyser. The PWM ramp-up or ramp-down may be really short (0.5s)
for the DMM to notice.
On Fri, Sep 19, 2008 at 4:47 AM, Sebastian Kuzminsky <[EMAIL PROTECTED]>wrote:
> Eric H. Johnson wrote:
> > The run-away problem s
Eric H. Johnson wrote:
> The run-away problem seems to be licked, at least for relatively slow speeds.
> I am, however, still getting following errors at higher velocities. These
> start to occur at about 3IPS. The motors should max out at about 12 IPS. Max
> step rate on the motors should be 20
Sebastian, et al,
The run-away problem seems to be licked, at least for relatively slow speeds. I
am, however, still getting following errors at higher velocities. These start
to occur at about 3IPS. The motors should max out at about 12 IPS. Max step
rate on the motors should be 20 RPS * 200 s
[EMAIL PROTECTED] wrote:
> I modified stepgen.c, about line 103 and 104 as follows:
>
> if (s->hal.param.maxvel > fabs(max_pos_per_s)
> s->hal.param.maxvel = fabs(max_pos_per_s);
>
> On the development system, whch is not connected to hardware, the following
> error has gone away and it basi
Sebastian,
I modified stepgen.c, about line 103 and 104 as follows:
if (s->hal.param.maxvel > fabs(max_pos_per_s)
s->hal.param.maxvel = fabs(max_pos_per_s);
On the development system, whch is not connected to hardware, the following error has gone away and it basically looks to be working.
Sebastian,
I should add, this is at approximately line 100 in function hm2_stepgen_instance_prepare_tram_write.
Regards,
Eric
I was poking around in the code, looking for anything suspicious as far as how position-scale is used. I see the following in stepgen.c:
float min_ns_per_step = s->
Sebastian,
I was poking around in the code, looking for anything suspicious as far as how position-scale is used. I see the following in stepgen.c:
float min_ns_per_step = s->hal.param.steplen + s->hal.param.stepspace;
float max_steps_per_s = 1.0e9 / min_ns_per_step;
float max_pos_per_s = max_s
Sebastian, et al,
Here is the latest. I tried entering the minimum number of hal commands to generate the problem. It took quite a few, so I stopped entering them manually and came up with what I believe is the minimum number of hal commands to generate the error. Here is the hal file:
---
On Wed, Sep 17, 2008 at 09:10:31PM -0400, Eric H. Johnson wrote:
> John,
>
> Thanks, that got it. Does a different parser get called for the hal file?
> Something other than bash? Because that exact syntax does work when run from
> the hal file.
Yes, basically it gets parsed twice.
The first tim
Sebastian,
By both values I mean both stepper motors. Hence the reason both showed this
problem. I generated the problem initially by doing a setp to a negative
value on the position-scale. Then for confirmation, I took my full
configuration, and first hard coded positive and negative scale values
12 matches
Mail list logo
