Advanced Search

I think this will solve the issue:
Will try today!
 

 

Looks like it is missing a value for the OFFSET_AV_RATIO variable, doesn't it? Should be 0.5 I think but check the QtPlasmaC docs.

Thank you for the quick reply.

The log you shared is from the Python script, but the important part happens on the EC300 board side.
Could you connect an RS232 interface and check the board's response when receiving the new configuration?

Thanks

I think the last time I tried to update to GTK+3, a bunch of the components no longer existed, like HAL_HideTable. Where do those come from?

Anyways, the basic functionality is working.
I still have to wire up and map the ATC spindle PNP sensors to detect clamping / unclamping and the sensors for the out position of the Carousel cylinder, before I can try to run a toolchange. But that should work out fine.
Once everything is working, I'll do a writeup how it's configured.

Allright!!!! Got the carousel working! Or atleast I can control and home it from the Probe Basic Gui and index it as well, altough I had to struggle a bit.

It's setup with the step generator PCB + 2 relays and two optical sensors.

- Had to figure out how to wire the relays in a way that both carousel directions were switching the "ON/OFF" circuit on the small stepgen PCB, but only 1 direction / relay would close the DIR circuit.
- Had to change 1 parameter in the M13 homing subroutine (P4 to P3), seems to be a typo.
- Had to configure the Index signal with AND2 logic for the M13 homing subroutine, so it looks for both the Index and the Pulse sensors during homing.
- Had some trouble with my NPN optical sensors, because I thought my Mesa 7i84 daughtercard was using NPN, while in reality I needed PNP.  

One problem, the drive wheel sensor flag overshoots the sensor by about 25 degrees during homing and index steps.
So when you home or index the carousel, the flag is passing the sensor completely due to deceleration it seems.
The result is if the follow up index movement is in the opposite direction, the flag gets detected after turning back only 25 degrees, with the physical carousel not stepping an index position, while the software does register +1 index pocket.
Not sure I can change decel with the stepgen PCB setup.

Two options to solve I think:
1- Create a longer flag on the drivewheel, so more like a lobe, which allows some more margin
2- Replace the drive wheel index sensor for a pulse flag on each pocket. The decel timing will give the geneva drive pin enough time to move out of the slot and properly engage.

Will try option 1 first, as I can just print a new disc with a longer flag.

 

Are you sure the probe_basic config folder doesn't get updated when you run those commands?

I was looking at the wrong machine folder initially, because I made a copy of probe_basic base folder when I first installed it.

Python gives very unhelpful errors and traceback.

+1 for Java!

Did ya try the wizard?

The motherboard has no onboard LAN?

Weird.

Your latency will likely be really bad because you have so many extra PCIe cards and stuff.

The latency of 2 identical NIC cards will likely differ slightly, especially due to different bus positions on the motherboard, which might cause issues with synchronisation.

Thanks for the pics, that is just what I needed to know.

At this point you had said to follow the instructions above, but those look to be for the EC300. Are they all the same files or are there different ones for the NVEM?
 

Thank you, I just ended up figuring it out and went to check the thread - what PCW wrote is exactly what i did (for others who stumble on this thread)!

i dont know much about marlin or how to use the pythonscripts, but with the W5500 branch from Drew, we have been copying grblhal, which has proven to be a good model. You can select build environment in the PIO extension and it will syntax highlight based on the build environment, or just build all of them. For the F4 branch, we didnt even need to make PIO board variants because most generic ones were included. Since there arent even that many options(clock, spi channel, etc), Drew threw them all out there for me at the beginning and I just had to add some defs and configure some stuff. Have a look at our other repo, I have been mashing this + grblhal into your new thing, and to try and work.
github.com/cakeslob/Remora-STM32F4xx-W55.../f429/platformio.ini

So far on the W5500 one, he had a bunch of SPI DMA options already included ( SPI1, SPI1-ALT, SPI2, etc), the common clock configs and I just mashed some defs and boards. I dont have it very clean but I was able to support all the other remora boards pretty easy.

# ---Setup spindle at speed signals---

net spindle-vel-cmd-rps => near.0.in1
net spindle-vel-fb-rps => near.0.in2
net spindle-at-speed <= near.0.out
setp near.0.scale 1.000000
setp near.0.difference 3.333333


#THESE 4 LINES BELOW WERE ADDED FROM MODLATHE TO TRY AND FIX encoder

setp lowpass.spindle.gain 1.000000
net spindle-vel-fb-rpm => abs.spindle.in
net spindle-vel-fb-rpm-abs abs.spindle.out => lowpass.spindle.in
net spindle-fb-rpm-abs-filtered lowpass.spindle.out

net spindle-fb-rpm-abs-filtered => gmoccapy.spindle_feedback_bar
net spindle-at-speed => gmoccapy.spindle_at_speed_led

So...I am not 100% sure if this is a gmoccapy issue or a deeper linuxcnc issue but I suspect it is something with the GUI.

A long time ago, I made a generic XZ lathe + analog motor + external incremental rotary encoder HAL/INI via AXIS gui. All worked well, and the side of the AXIS GUI displayed the spindle speed bar plus the red button indicating if spindle was at speed or not. It worked correctly.

However, now I have build a different machine: a custom XZC lathe with a STEPGEN controlled servo spindle, and I am trying to simply have the same thing work where when I run the servo motor, I see the RPM based on what the encoder sees. The wiring of this machine is all the same as the last one minus a C axis and servo.

BUT... NOTHING I do allows me to see this information and I cant figure out what it is. Axis GUI does not display any spindle speed displays. I thought maybe it was an AXIS issue and switched to gmocappy, which I atleast was now seeing a spindle speed bar. However, when i turn the spindle on, I just see the default comanded rpm instead of what the encoder sees.

This is the relevant section of the HAL:


#Original 4 lines from "MODLATHE" working hal/ini
setp     lowpass.spindle.gain 1.000000
net spindle-vel-fb-rpm => abs.spindle.in
net spindle-vel-fb-rpm-abs abs.spindle.out => lowpass.spindle.in
net spindle-fb-rpm-abs-filtered lowpass.spindle.out

net spindle-actual-rpm spindle-fb-rpm-abs-filtered => gmoccapy.spindle_feedback_bar
net spindle-actual-rpm spindle-fb-rpm-abs-filtered => gmoccapy.spindle_at_speed_led

#above 2 lines added in attempt to get gmocappy to display the correct 


HOWEVER, any time I try to run the program, I get "spindle-fb-rpm-abs-filtered" but no matter what input i place into those two lines it says that pin does not exist

HALMETER: IN halmeter, I see abs.spindle.out and abs.spindle.in working correctly. Also, if I remove the belt from my encoder and monitor spindle-at-speed, if I command the spindle to move and then manually rotate the encoder, I get the value to change from true to false - which makes me think my setup is working and its more of a GUI issue?


Can someone help me figure out what I am doing wrong and how I can get gmoccapy to display my encoder RPM and if the spindle is at speed or not correctly?

my MODLATHE hal/ini is my original machine that had the working gui to show the encoder rpm and if the spindle was at speed or not.
my C+TURN axis hal/ini is my new custom machine i am trying to set up

Nice work! Using PIO board variants might be the way to go. That's how Marlin has managed it and it's so much like how Mbed uses custom targets. They use some custom python scripts to make the magic work.