Advanced Search

Fastfred wrote:

 I will try to figure this out my apologies That I haven't picked up on this yet.
 

No worries, you'll get through this even if you feel like you're lost now.

Takes a while for HAL to sink in - it did for me.

I was able to solve the error with maxvel too big by changing the steps per revolution to 2500 in the servo controller. Now I just have to solve the problem with the MVO.

No I did not copy the whole thing just the hal part for HLFB thats it.

Thanks

You should not JUST copy the three files I posted; at best you could insert the snippets I posted first (there's a section in my custom.hal that matches it, you could cut-n-paste that). You *should* be able to use my HLFB logic as-is if you have wired each servo to its own enable/fault pins, and have a gantry-style (dual Y) system.

With a basic understanding of how HAL works, you should be able to figure out my hal setup. I'm not an expert at HAL so my logic is pretty basic. The bigcnc.* files are pretty much right out of pncconf (but tweaked) and the custom.hal file is all mine.

I really do appreciate the help I am getting I did say I don't understand this part yet and I am sure I was told to copy the file that was posted  djdelorie and just change the card pin naming to fit for my needs I will try to figure this out my apologies That I haven't picked up on this yet.

Ok ok. Spi was a pain for me until I got it sorted that's why I wanted to be really sure it works. Nothing works without spi.

There are a few hardware bootstrap jumpers on the Lan9252.
They are described in the schematics for lan9252 evaluation  board.
I have them marked on all board schematics. 
You can compare them with your board, perhaps there is something different?

I guess it wouldn't be too difficult to replicate your board and try to troubleshoot it.
Can you make sure to push relevant code to github and I can have a look at that.
I'm pretty sure I can puzzle together the hardware.

You are going to end up designing a board, just start haha.
You mention I2C. If you need it, yes. Otherwise no. I used it for 
plasma arch voltage. Worked great, but if you don't need it don't include I2C.



 

Fastfred wrote:

  Unless I still having a naming issue with the pins unfortunately I still don't understand this part yet. 


 

I think you don't understand HAL naming and so forth.

The HAL section you posted earlier has some issues:net hlfb_x => and2.0.in0
net enable-faults => and2.0.in1
net x-fault <= and2.0.out
What the above does is connect signal 'hlfb_x' to pin 'and2.0.in0'

And if the signal doesn't already exist when LCNC gets to that line in the file, it creates a signal with that name.

Problem is, nowhere in the section you posted is another pin connected to either signal 'hlfb_x' or signal 'x-fault'  So the 'and2.0.in0' and 'and2.0.out' pins are not connected to another pin.  The AND2 function isn't doing anything.

You need to link two (or more) pins that already exist for the logical function to work.  You create the signal names, but the pins must already exist in LCNC.

net SIGNAL PIN1 PIN2 is the format.  You can put the connections on different lines, and the "=>" symbol is helpful when reading the file, but not necessary.

All of which means your attempt (I think) to add a time delay in the amp-fault / amp-ok sequence isn't going to work.  Your physical inputs are connected directly to the amp-fault-in pins, and the time delay logic isn't in the equation.

Try this.  I've put each part on a separate line - make the file longer but can be easier to read for some people:

net  x-fault-in         hm2_7i96s.0.inm.00.input-10-not
net  x-fault-in         and2.0.in1
net  enable-faults  and2.0.in2
net  x-fault-delay   and2.0.out
net  x-fault-delay   joint.0.amp-fault-in

In order to limit costs and continue tests maybe I should try to build a lan9252 prototype board with eeprom spi and i2c.

Thanks will look at them soon and try.

Here are my full configs, since I didn't know which "part of the file" you meant.

Would you mind sharing that part of the file ?

I set VOLATILE_HOME for each joint in my config, and I know it works because if I push the OFF button in the GUI, all the axes become unhomed.  However, if a servo fault comes in, that also shuts the machine OFF but in that case the axes remain homed.  If I ON-OFF via the gui after a fault, it unhomes. This is neither what I expected nor what is documented(1). How do I get the axes to unhome on a servo fault? (the fault comes in via joint.N.amp-fault-in)

(1) "If this setting is true, this joint becomes unhomed whenever the machine transitions into the OFF state. "

Edit: I'm using version 2.9

I spent some time working on my machine's fault handling, and in the end all I had to add to get it to do what I wanted (stop machine on fault) is to add these (in addition to the configs I posted earlier):
  net x-fault      => joint.0.amp-fault-in
for each joint.  I also set VOLATILE_HOME for each joint in the *.ini but it didn't do exactly what I wanted.
Given that I use joint.N.amp-enable-out (aka x-enable, set in MACHINE.hal automatically) to enable the clearpaths, as soon as a fault comes in, it posts a warning and shuts the machine off, which disables the clearpaths, which clears the fault.

My ESC TEST VALUE reading is fine...
i tried a lot of things but dont know why i cant get the eeprom correctly set up. Maybe its something with the board I dont know

I tried changing the naming, but had to use different name because was already assigned to pin.I get joint fault as soon as i try to enable I did try changing delay thinking that was it but no luck.  Unless I still having a naming issue with the pins unfortunately I still don't understand this part yet.