Advanced Search

Pcw,

Thanks again for your effort.

What do you advise at this moment?
You can tune the planner with scurve jerk value in the hal section. This changes the accelation profile.
This jerk value is not integrated to the .ini file so far.

I assume you could tune your ini config to run without following error? Or is this not the case?

Indeed if you set acceleration to 200, the scurve max acceleration will be 400 at inflection point.
Exceeding your max acc off 240.

I don't use remote desktop. I did a test with three working youtube videos

Thanks for your quick reply.

I haven't changed any drive parameters.

Since i am new to Servo tuning, its quite confusing to conclude, whatever i am doing is correct or not. Now i have a fundamental question,

With the above setup is it possible to achieve 15,000 mm/min feedrate within 20 micron positional accuracy and +- 20 micron repeatability? I doubt whether the control loop is fast enough to reach this speed and accuracy ?

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.