Advanced Search

AMD still has driver support on Linux for the 500 series gpus. I'll try using my integrated graphics but it hasn't worked before. Which is why I have a card in the first place.

Amd readeon RX560

Non-existant user wrote:

Should we delete the two duplicate replies above without the quoted text?

Yes please, i tried it myself but i guess that is not possible. Thanks!

OpenGL issues, what graphic card does the PC use?
Can it be removed? If yes, remove it and test with the onboard video.

PCW wrote:

if estop-latch.N.ok-out goes false, one of these must have changed:

estop-latch.N.ok-in  goes false
estop-latch.N.fault-in goes true

So I would watch these in halshow or halscope to see whats happening.

I also don't understand why you have two estop latches. It seems that one
should be sufficient (adding some logic if you need to add fault inputs or OK inputs)

 

Hi, thank you for your quick reply. I have been looking at these halshow/scope bits but could not get it to click.

I have tried with two latches, with the idea that one will be for external estop (input 00) and the other for software internal estop (user enable out).
I also tried with one, linking the ok-in for user-enable out and fault-in to input00 external estop. No succes.

I will keep trying, thanks.

If you have any more sugestions i would be happy to hear them.

Unlogic wrote:

I documented my e-stop setup using an external safety relay in the post linked below:

forum.linuxcnc.org/12-milling/50559-opti...rsion?start=0#284533

Maybe it will help you get your setup up and running.

 

Hi, thank you for your reply. I have read your documents on your build, very impressive, thanks for the detailed sharing and documenting.
I saw you used the oneshot function, i have tried implementing it like you did but no succes. I will try again once i got the time.

Thanks, cheers

This solution worked, but when i try to start my cnc file, it gives me an error. error report in the attached file.

Thanks for the tip. It was loading the wrong file.

HAL files specified in the HALFILES variable are found using a search. If the named file is found in the directory containing the INI file, it is used. If the named file is not found in this INI file directory, a search is made using a system library of HAL files.

tommylight wrote:

Yes it is as the change must also be reflected in HAL, so it would require having two of the same configs with and without the inverted input, very easy to do and use, but can not be used if both are to be used in the same run.
NO or NC does not matter much, but having both NC would make it possible to use the same input when wired in series.

Today the z probe arrived, I connected it to pin 11 which is where I have the 3d probe. In the hall file I have removed the "-not" so that it works like NC. I have configured it as a basic probe and it works correctly.

Now what I need is to connect it to the same input as the 3d probe (the 3d probe is NO) if possible. I have searched for information but the truth is that I have no idea how to do it.

Tonight i poked around in the rtapi & hal source code.
To my suprise was able to load multiple instances of hal, each using their own memory region.

file : hal_priv.h
Add a few define's


file : hal_lib.c
Normally it uses : int init_hal_data() ; Then it uses a previous declared pointer hal_data->....
We cannot use this for initializing multiple instances. Solution is to change the function a little bit.


new file : hal_instances.c
This file creates the hal instances. It allocates the memory for each instance.
Then it initializes each hal_data_t struct using the above function : int init_hal_data_struct(hal_data_t *data) ;


Then added a init function to halcommand.
Then you can type ~./bin/halcmd init
Then in terminal :
user@pc:~/hal/bin$ ./halcmd init
hal init instances.
Initializing HAL instances...
Successfully allocated shared memory at address: 0x7f0557fe8120
Each hal_data_t instance requires 288 bytes of memory
Initializing HAL instance 0 at address: 0x7f0557fe8120
Successfully initialized HAL instance 0
Initializing HAL instance 1 at address: 0x7f0557fe8240
Successfully initialized HAL instance 1
Initializing HAL instance 2 at address: 0x7f0557fe8360
Successfully initialized HAL instance 2
Initializing HAL instance 3 at address: 0x7f0557fe8480
Successfully initialized HAL instance 3
Initializing HAL instance 4 at address: 0x7f0557fe85a0
Successfully initialized HAL instance 4
Initializing HAL instance 5 at address: 0x7f0557fe86c0
Successfully initialized HAL instance 5
Initializing HAL instance 6 at address: 0x7f0557fe87e0
Successfully initialized HAL instance 6
Initializing HAL instance 7 at address: 0x7f0557fe8900
Successfully initialized HAL instance 7
Initializing HAL instance 8 at address: 0x7f0557fe8a20
Successfully initialized HAL instance 8
Initializing HAL instance 9 at address: 0x7f0557fe8b40
Successfully initialized HAL instance 9
Total memory used for HAL instances: 2880 bytes
All HAL instances initialized successfully.

So far it seems to work. But now we must dive a little deeper.
What should be the next step? Maybe do a halcmd show..

This is for example the  ~./bin/halcmd show function


In above function hal_data->.... is used, this is just one hal instance pointer.
in the file hal_priv.h its declared : extern hal_data_t *hal_data;

So now we know we just have to implement our instance regions.
hal_data_t *hal_instances[MAX_HAL_INSTANCES];

Will try to test if this works.

If you did configure as suggested, chances are one of your Y joints is spinning in the wrong direction, the one that moves after homing is OK, the other should be reversed, but beware as that requires reversing the search and maybe latch velocity directions.
Can be done easily by adding or removing - in front of scale and home search and latch velocity for that joint in the ini file.
To me sure, make a new very basic config with only steppers, but choose two sets of step/dir signals for Y axis, save, start the config and jog SLOWLY the Y axis. Do both run in the same direction?

A 7I96S can replace a 7I76E if you can get by with the more limited I/O
(11 inputs and 6 outputs instead of 32 inputs and 16 outputs))

You can add a 7I84 to a 7I96S if you need additional I/O
(this adds 32 inputs and 16 outputs)

Also 7I76EUs should be available in about 4-6 weeks
(7I76EU is the universal output version of the 7I76E
that supports sourcing, sinking or push-pull outputs)

mBender wrote:

Below is the current set up as of last night. Bench testing worked as expected. It goes from there to a Parallel port break out board. This allwos me to use my machine with LinuxCNC and laserGRBL with just changing a plug. I tried to find out the current rating of the 3.3V and 5V power supply of the Tang Nano 9k. According to the schematics, it seems like that there is a TMI7003C DC/DC Step down, which gets it's 5V directly from the USB C port. If I read it correct, it can supply a max current of 1.5A total. That'a including the power for the FPGA,...It seems like the each Output of the Tang can drive up to 24mA. Which obviusley need to be deducted from the 1.5A plus the other current demands of the FPGA board. Still I believe there is plenty of current to drive secondary operations.The 1.8V needed for Bank 3 is not availbale at FPGA board. I was wondering if I could just use 1 or 2 1.8V outputs, set them pernantley to high and use them as supply voltage for any leverl shifter at Bank3. Opinions? 

 

My personal plan if I needed more gpio was to ignore the 1.8v pins and using the 3.3v pins either use a shift register, see if I could add i2c GPIO expansion support such as the mcp23017, or reserve the FPGA purely for estop, home pins, and steppers and use something else for things like MPG controls and such. github.com/wezhunter/ESP32_LinuxCNC_MotionController_RealTime perhaps, since I have a pile of esp32S2's around. 
I also ended up with a XHC WHB04B-6 wireless MPG that currently satisfies 90% of my control needs, so I don't have a lot of willpower to make a UI that needs a lot of GPIO.

I know that doesn't solve your problem, but just thought I'd mention it for ideas. 

Also, a common LM317 is easy to make it output 1.8v from from the 5v input, as another option. 2 capacitors and 2 resistors. It's hard to even burn them out, they shut themselves down with overcurrent.


 

Aciera wrote:

I think you might be missing this in your hal file:

net tool-change iocontrol.0.tool-change iocontrol.0.tool-changed

[edit]

for troubleshooting it might also make sense to use the 'show halconfiguration' to watch the iocontrol.* pins like
iocontrol.0.tool-prepare
iocontrol.0.tool-prepared
iocontrol.0.tool-change

[edit2]

Just so we are on the same page, I presume you have tried the suggested (ie reversed M6 T..):

[code]T.. M6

[/code]

Reversing to Tn M6 did not help.
Adding also did not do the trick but then I tried the second part of your suggestion of watching those iocontrol pins that relate to tool change and noticed that tool-prepare goes high that led me to think that it might be waiting for the tool to become prepared, so I tried thisand ended up with MSG messages displayed and some actual motion to happen. Thank you very much!!! That was a silly mistake as usual!

I will need to play with the scale some (and look into the choke you mentioned), but it now works. I was replacing "net spindle-output <= pid.s.output" with "net spindle-output => hm2_7i97.0.pwmgen.04.value", when I needed both present in the hal file. Another bonehead move...

Thank you for helping me.