Advanced Search

Thank you. Although I am not sure what is the difference between 'machine movement' and 'axes position' that you have mentioned, I presume that AXIS preview does not reflect the underlying kinematics of the machine, correct? I think the fact that AXIS preview works this way can cause a lot of confusion to newbies like me. If this is the case, then what do the red, green, blue directional vectors shown in the AXIS preview tell us? Is there any way to configure AXIS preview so that the directional vectors agree with the underlying kinematics?

Anyway, after experimenting with 3axis-tutorial.ini, I can now see the effect of reversing the X coordinate in vismach. It turns out that reversing the coordinate in inverse kinematics alone is enough to see this effect, no need to modify the forward kinematics part. I also try with Y and Z as well. Reversing Y works as expected. However, as I try to reverse Z, I encountered error messages telling me that linear move would exceed joint 2's positive limit (no matter I move to +z or -z), and I am not sure why.
 
 

I never managed to keep Hal show on top and didn't have problems.
Once everything runs I might reduce them but while developing it really helps so see all states while running some routines.
Just saw halshow got some nice updates maybe now it keeps on top of probe basic.

I have looked through the remora documentation and there are software encoders mentioned with a frequency up to 30kHz. If I get close to that number with a rp2040 I am fine with that. That would result in theoretical encoder resolution to roughly 360ppr with 5k rpm and 30kHz max input frequency. It is just the question if the pi2040 is up to the task of handling these things

Bump.

Any solutions to this? 
I have done the add device rule a bunch of times and the wireless controller was detected, but only once the "test device" window got populated with the pins and was responding to the buttons on my controller. Rest of the times I couldn't get it to populate and remained totally blank. Also there is the problem of the Pncconfwiz freezing up and needs restart.

Cant do this anymore bye all wrote:

The correct names joint.xx.count, joint.xx.enable and so forth. Open axis and look at the hal configuration menu.

I personally would never, under no circumstance, ever attempt jogging an un-homed machine-tool (again). Don't ask me why's that, too shy to explain. Great info none the less. Suspected it was something related to the net/name or something. 

axis is for jogging an axis, which needs to be homed.
joint is for jogging a joint which doesn't need to be homed.

I think these were some of the major changes from 2.8.xx to 2.9.xx

The correct names joint.xx.count, joint.xx.enable and so forth. Open axis and look at the hal configuration menu.

From PCW response, if any peripheral card such as 7i77 watchdog HAS bit, the main power supply must be turned off.For implementation since 7i77 does not have a dedicated digital output. One way is to dedicate one preferable two of the 7i77 digital outputs to signal to the main power supply circuit to cut the power to the machine. I will update the schematic when I get chance.Good night, folks
 

OK so ethtool is not installed

sudo apt-get install ethtool

 

This is like a century ago I forgot but was it in the naming of the nets that defines whether you can jog with and/or without homing?

axis.x.jog-enable -vs- axis.joint0.jog-enable

An HAL expert would know...

cnbbom wrote:

What project would you recommend to me to work with 4 to 6 axes?

3 axis!

Start with 3, never ever start with more. That makes the learning process much more enjoyable.
Starting with 6 will almost always end up in defeat and abandoned projects.

You can jog without homing if add jogging, enable & counts for each joint.

 

Your pc is to old, see the requirements at the top of the installation docs, it states the minimum opengl requirements for vtk which is the backplotter used in probe basic and qtpyvcp uis. Can use a graphics card to resolve or a newer pc.

The user tabs are predefined ui's, you should be able to copy and paste to them. The latest version uses the var files for all parameters so they are callable from toolchange remap, same for all probe paramaters so they work if called from gcode etc.

Qtdragon is a good option too, more flavors is a good thing. As for leds for IO, I had that in there at one point but it caused some issues on faster machines and some computers, it slowed the non realtime layer down for some reason so I removed. But all that is available with halshow.

rthorntn wrote:

Awesome, did you use any opto-couplers/digital isolators, are the nine 16-pin IC's only level-shifters?

Well spotted, correct, those 9 parts are indeed the level shifting. Features digital isolation also, all in one part. I apologize for omitting the schematic for now, once I have it cleaned up and arranged I'll put it up. I'd like to test the board prior though. Regardless, here's a visual below of how it's arranged (ten inputs). Additionally, I'm getting us an ultra-low ripple Isolated 12V Supply done for that board. Plugs right on the main. If we are to isolate this FPGA/Motion Control thing, might as well isolate it true & properly!! 

Here's the cool visuals: