Advanced Search

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.

Did anybody get it to run with Rods guide??

E.

I think they all describe steps to bring data in and out of the drive, steps that are missing in the lcec case. SOEM mentions fragmentation/defragmentation. Not more complex than that. I haven't found out if the hardware I have can be used for a prototype.
I'll keep searching.

Thanks for the reply. I've been busy with roofing, plumbing, parquet flooring etc but managed to sneak out to the workshop finally.

I've managed to get the spin boxes to appear in an otherwise blank macro screen, which is some form of progress. This was by removing the "notouch=1 -U norun=0 -u" switches from the EMBED_TAB_COMMAND line.

However, the gmoccapy screen is now bigger than the primary display once gladevcp starts up. That doesn't seem to prevent anything new from working otherwise. Presumably I need to correct the screen resolution, possibly by installing better video drivers? It used to fit the screen.
EDIT: the native resolution of the Hanspree HT225 is 1920x1080, same as the second display. No end of playing with display seems to prevent the GUI spilling over beyond the extents of the display(s), other than commenting out the EMBED_TAB line.

My path statement looks like this but perhaps I need to read up on linux path syntax:SUBROUTINE_PATH = ~/nc_files:~/lathe_macros:~/subroutines:~/python
...where those subfolders are in the folder where the INI file is held.
EDIT: I now see I should use the dot character rather than tilde in linux to denote a relative path. I will try that...
Beyond that, when I run linuxcnc from the command prompt, it reveals a royal mess. Clearly gladevcp isn't happy (see attached log file).

I tried installing python-rsvg but it didn't like that:
murray@LinuxCNC:~$ sudo apt-get install python-rsvg
[sudo] password for murray:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package python-rsvg

There are a few things going on here, to say the least - could you suggest what I focus on in the first instance?
 

The 7I76EU inputs have a threshold of 60% of VFIELD when going positive and 40% of VFIELD when going negative.
This means with 24V VFIELD, a voltage below 9.6V is read as low and a voltage above 14.4V is read as high.
This  is called hysteresis, and is deliberate behaviour for noise immunity. With a 10 K pullup you end up just in the middle
of this input threshold range, You need a stiffer pullup resistor (say 2.2K) so that you have a valid input to the 7I76EU.

Thank you. I'll learn. And ask there if don't catch something.