Advanced Search

compared to mesa which uses memory map with peripherals mapped to addresses in the memory and need cpu parsing to read write addresses. but this allows dynamic configuration of the driver.

I should note that a CPU is not required with HostMot2 and no interface CPU is  used in PCI, SPI or EPP
interfaced configurations. Interface CPUs are only used with  Ethernet, USB, and serial interfaced
configurations to support the more complex wire protocol.

 

Thanks for the response and my apologies for delay and update - retired life got super busy for a couple weeks... I'm not sure I explained the whole episode clearly - I'll try again.

1) LinuxCNC was reinstalled on the same hardware but with an SSD instead of spinning disk.
2) StepConf was invoked to create new .INI and .HAL files for this new installation - there was no attempt to 'configure' anything using StepConf because I planned on copying over the .INI and .HAL files from my previous working install (spinning disk)
3) For grins and giggles - I attempted to load and run LinuxCNC before overwriting .INI and .HAL - of course it didn't work
4) I overwrote the initial .INI and .HAL files with my copies from the working installation (spinning disk)
5) Initial loading and running of LinuxCNC worked fine
6) Thinking I again had a functional system, my mind went into autopilot and my fingers took over - I wanted to move the router to the center of the workspace an pressed the SHIFT-RT Arrow for a rapid move 'X' and... it jumped a bit and stopped
7) Exactly the same with SHIFT-LT Arrow, SHIFT-UP Arrow, SHIFT-DN Arrow, SHIFT-PgUp and SHIFT-PgDn.

I have not yet run a job to see if it works - I doubt it because any rapid moves would cause a problem. I've done some reading on steppers, timing and BASE_PERIOD and I'm trying to find the timing charts for my steppers. I'm thinking that since LinuxCNC uses software step generation, the new SSD may be just too quick? Although - the configured BASE_PERIOD should be independent of the any HD speed.

My other thought is - my latency test resulted in > 70,000 nS Jitter in the Servo Thread and almost 56,000 nS Jitter in the Base Thread. With Steppers - I'm not sure I'm concerned about the Servo Thread numbers, but when using StepConf, the maximum entry allowed allowed for Base Thread jitter is 50,000. While the instructions for the Latency Test say 'abuse' the system when testing... when running a job - I don't much touch the computer for anything significant - certainly no web surfing or multi-tasking other apps.

Not sure any of that update helps you all help me - I'm reading LinuxCNC forums, documentation and Wiki as well as trying to find timing diagrams or tables for my steppers. Anything anyone can suggest would be really helpful... possibly reduce the acceleration?

EDIT: I should have included some hardware specs...
Dell Optiplex 7020
I3-4150 @ 3.5GHz
8G RAM
Samsung 256G SSD
 

At the end those two adresses are not readable and i change them according the the mitsubishi datasheet with two other adresses and it works thank you so much for your help
i have one last question please now i want to read data from different slaves (3 servo dirvers) how can i do that , i've tried to add a second device initialization on the hal file and i created a new comp file but the problem is one of them connect and the second slave doesn't respond

new discovery, there is no sdos data in the eeprom.

could not find any in the documentation or in a sanmotion servo eeprom, the data is probably read from the firmware.

Can you post your hal and ini files?

Most of the time, when I try to probe, I get a debug message saying the feed rate (most often) or tool is not set (says to load tool 0 when its set to 99).  Which they are set (see attached screenshot).  If I "change" them to the same value, it works fine.  I am using the latest update (from a few weeks ago).  Also, note that the parameters are saved correctly in the .var file.  Not sure what else to check.   

Are holding registers at 0003 and 0004 readable?

I have a question about the spindle speed control.
This is a lathe configuration. The previous owner has the chuck set as "spindle" so I'll be using spindle to describe it going forward. I hope this alleviates some confusion.

Anywho...
If I tap forward, the spindle the scale whitens and shows a green bar on the scale indicating RPM on the scale. I can tap +/- to override the spindle speed +/- 50% as one would expect.

However, if I click reverse the scale switches to a negative scale but it stays grayed out and the spindle shoots up to about 2000 RPMs with no green bar. Also the spindle speed cannot be overridden.

I don't believe this is an issue with the VFD I suspect it's some configuration issue. Correct me if I'm wrong.

Can someone shed a light on this? 

Thanks in advance.

Hello Bro's;
I m trying to control (read/write ) data from MR-JE mistubishi servo drive using the 7I76EU mesa board, using PKTUART, i could reveive data from mitsubishi HMI but when i tried reading the data from the servo drive, it seems like the connection happened but there is not data reed and when i run the linuxcnc it take time to open not like usual time and two type of error appear as shown on the pic bellow. you will find also the .HAL configuration file and the C file where i put the adresse i wanted to read 
 

whew yes the init light is blinking. I will look into what I need to do to un screw up my card and hopefully get the correct outcome this time lol

already a good starting point

github.com/multigcs/esitool

I was reading about g-code remapping again just now. M3 isn't remappable, sadly, but I found that there's an available remap for M6 ("ignore_m6") which would avoid the bug that started this thread. So that's interesting, but not long term, since I might actually want to implement tool changes.

I also found that, while M3 isn't remappable, the S comand is. So there might be a way to use that.

G1 Z0 to fool at-speed? Devious! I'll give that a try. M66 is an interesting idea too. I'll think about that.

Right now my solution is all hidden behind a perfectly normal looking M3, which is kind of nice. (Well, unless an M6 happens too quickly after the M3, as I've discovered....)

But first I have to do "just one more test carve" on a piece I want to take on vacation later this week...

ok. i think i got it. you create a bus with width of the data frame, clock the data in/out via SPI, and map each peripheral to a certain bits in the bus to use as input/output control registers. very elegant, simple and lightweight, the only inconvenience it needs driver rebuild for peripherals changes.

compared to mesa which uses memory map with peripherals mapped to addresses in the memory and need cpu parsing to read write addresses. but this allows dynamic configuration of the driver.

It wasn't missing it was dryed out during the years and pulled down the battery voltage. Thats the reason the servo amp always complained position lost. I reordered the cap already but you know how it is: Nothing is as permanent as a temporary solution