Advanced Search

Yes.. power up.. start linuxcnc... loose the brakes.. bring all joints to the sharpie marked position. Then reference/home to the index of every single encoder.
After this all joints at zero. B axis has offset 1 degree that there no failure message comes from linuxcnc because.. if all joints at 0 degree they are in singluarity... thats why its needed to brin as example a small offset to the B axis.

Thats how i understand it.

I really appreciate you info dumping here; so much good stuff to know.

I had a 7i80 with a 7i85s and a 7i37 working with 3 stepgen, I tried reconnecting it and only a step dir signal comes out of the y-axis and that's it. I loaded the firmware 7i80db_16_7i85sx3d.bit. I don't understand what could have happened, I put it away and all three axes worked.

hitchhiker wrote:

I only had zero x y z in genser mode... not correct?!

 

First at powerup you have to zero every joint, did you do this?

disclaimer:
I have not yet had opportunity to run a LinuxCNC robot, except for playing with the sim. I have spent many hours programming/repairing Fanuc and ABB robots. Some day when I have enough projects completed to make more space in my shop I want to buy an old robot and put LinuxCNC on it.

I only had zero x y z in genser mode... not correct?!

I know that when i rotate A axis the B axis make moves.. because the mechanical stuff inside the hand goes over small gears.. but this should not be the problem or???

Thanks

hitchhiker wrote:

I have a small success...old ini... home and homeoffset to zero.. jog to marked position (edding/sharpie on the joint..).. then homed to index.. bring all in a non singular position... start g code...

I think this was a step in the right direction... but z stays not on z on the table.. but on the linuxcnc dro
 

Are you saying Z does not operate correctly on the machine although it displays correctly in the DRO? If so then I would first suspect the problem would come from having some joint not zeroed at the exact true zero point. I think a slightly incorrect DH parameter would create the same symptom.

Ok, I did not know about that is an original Chinese design, thank you for your observation. and comments. and thank you for this card that give me the chance to deploy a laboratory over this card.
If some one has been testing this card, please share you experiences and conclusions

But what was on lines 1-4? The screen shot of your code does't show. It would have been better (and used less bandwidth) to upload the actual g-code file, rather than an image of a screen shot.

youtube.com/shorts/PnO5MxeK1Xg?is=1G0Dy59B0bhhUQdd

I have a small success...old ini... home and homeoffset to zero.. jog to marked position (edding/sharpie on the joint..).. then homed to index.. bring all in a non singular position... start g code...

I think this was a step in the right direction... but z stays not on z on the table.. but on the linuxcnc dro

Heeeelp thanks

To analyze problems with gcode, it is so much easier to load the relevant file into your own simulation and test it than to look at a screenshot and make some assumptions...

1) grid
It was never intended to switch sizes on g20/21.
But I see in the metric sim the mm sizes are not metric at all.
strangely in the inch sim, metric and imperial sizes work properly.
This seems to be in the glcannon code, so is not fixed yet.

2) paused runtime
ya that's not right and I think its fixed now.

3) mode switching
I created a hidden 'auto mode switch' option - enabled in the preference file only.
I think it does what you want. please try it out and if it is I will make it a settings option. (if running a program, the file tab will still not change to the file page FYI)

4) keyboard pausing
ok I removed the mode check so it should work everywhere.
I could not get the spindle lowering to fail with the pause button after this.
please advise if there is more to look at.

All just pushed to master

tommylight post= You did neither, seems you are hiding something...
Yet you ask us for help.

I have to trim the size of the image down otherwise I get an error saying the image is too big.
If for some strange reason I decide against my better judgment to come back here again and ask a question, do me a favor, don't reply to it.
I really don't care if you know the answer. I am going to ignore anything you post from here on out. If it was possible to block you from seeing anything I post here, I would. 

Have a day you deserve.
 

You’re right, it’s actually too small for a full setup.

But you could use it, for example, as a satellite, as an extension or for a distributed setup.

www.youtube.com/shorts/2vjq0Kd5WOE


In principle, a single-axis setup would also work, though it’s always a bit tricky to have mixed setups.

I’ve done a test compile:

---

Resources | Usage | Utilization

---

Logic | 956/1152 | 83%

and it fits

with USB/Serial it's to slow.



EDIT: BTW, the boards in the list are just the ones that have pre-defined pin assignments and can therefore be used easily in the Flow frontend. However, it’s also quite easy to add new boards, or you can let me know which ones you’d like to see included – as long as the FPGA supports them, it’s no problem.

Just an idea of what you can do with a parallel port(s) with Linuxcnc. I had a double Z axis (Z and W), 6 spindle gang router (3 spindles on each Z), all the spindles with individual control using analog speed commands, individual +/- limits for each axis. All ran off of 3 parallel ports.

There are even some special things that you can do using a parallel port that you can't really easily do with Mesa cards and hardware stepgens. I had a machine that I retrofitted to Linuxcnc, that I wanted to keep the ability to plug in and reuse the original control. It had it's own driver box for the step motors and used individual commands to directly trigger the stepper coils rather than traditional step/dir commands. I was able to directly replicate those signals using Linuxcnc's software stepgen and output them to a parallel port.

timo wrote:

I had issues getting a 100ppr encoder to work reliable at 600 rpm. The cheap BOB seemed the issue, the system was loosing signals.
 

You are right, this is PC817 optocoupler bandwith issue.
I did some test, and PC817 response time depends on input current, if current increases, the bandwitch decreases (is this saturation?).
However 1 kHz is very low and PC817 sure can more.
If you use 5V encoder, you can safely connect it directly to LPT or MESA pins.
Most of 24V encoders with NPN outputs can be connected directly too, but you must check outputs voltage before (some has builtin pullup resistor an thats can burn low voltage inputs.)  
MESA can more than encoder. Low cost optical encoders have bandwith 100 kHz, this mean max 2000 p/r at 3000 RPM.
LPT depends on jitter, but in practice 100 p/r is max at 3000 RPM