jtaseff

Thanks for the update. Can you also update the main deltatau.com support page? Not all of us are in constant contact

Hello, A few people from our company have tried to email the support@deltatau.com address and a few individual addresses we have contacted before. All of them bounce back after a few days as "delivery is delayed by server". Is it just us, and can you check your IT department? GF / Microlution

We have a similar issue where closing the Tune window will cause our ECAT network to drop out momentarily. Happens almost every time on firmware 2.4.1.2 and IDE v3. Downgrading to firmware 2.1.1.3 and IDE version 2 seems to solve it. Edit: On Power UMAC 465.

Will chime in that we are experiencing the same. Our own HMI software uses a number of gpascii threads. If we have the IDE open while running our software, everything slows to a crawl. Our response time for queries and commands gets noticeably delayed, sometimes timing out or getting an empty response. Trying to open the IDE tuning tool and system setup tool can take minutes. This all started with IDE version 3.x, and happens with both 2.1.1.3 and 2.3.2.5 firmware.

Another issue we've seen in the same realm - if we update either the firmware or IDE, we usually end up having to recreate the whole pmac project and re-import all of the script files. The new IDE generally seems to be okay talking to older firmware if I build a new project. But then if I switch computers, an old IDE has trouble loading that new project.

For anyone else trying this, I did find a way around the csglobal problem: In the .tpl file, I can have it run this to output the currently addressed CS: &1 Ldata.coord csvar1 csvar2 &2 Ldata.coord csvar1 csvar2 This produces the following in the .cfg file on fsave, which seems to load things in properly on fload. Ldata.coord=1 Q1024=10 Q1025=20 Ldata.coord=2 Q1024=30 Q1025=40

Is there a way to do it by name when accessing Coord[x].Q, or a way to programatically find the Q-number of a named variable? Would much rather be able to save by name if the project changes around, instead of tracking Q numbers around by hand

Hi there, We're testing out using fsave/fload instead of our implementation of something similar. Couple of questions. Is there a way to deal with csglobal variables? I tried putting this in the .tpl file: &1 csvar1 &2 csvar1 And in the .cfg file, I only get this, which won't work to reload to the correct coordinate systems: Q1024 = 10 Q1024 = 20 Additionally, is there any way to have it work with variable names? For example, if I always have it fsave a global by name, myvar1 gets stored as P1111. But if I update the project to add a new global before that, myvar1 is now in P1112, and the next fload will put the saved value into the wrong place in P1111.

Say I have a bunch of programs which all get loaded through gpascii. They all have numbers #defined, such as #define progMeasurePart 100 or #define progDrillPart 101. Is there a way to check if these are loaded/exist in PMAC by number? The only way I can figure out is checking if (prog[n].Number==progMeasurePart). However, then I have to loop through from prog[0] up to an unknown number of programs that might exist until I find or don't find the one that matches the number I want. This structure is also not documented.

Just curious, why are the firmware and IDE manual up to date on the File Depot, but the IDE is 2 versions behind?

Ran into the same. We ended up having to update the IDE to the "January Patch 2.2.1.25", create a brand new project, and re-add all of the files to it.

Screenshot is attached, and a listing of backup Motor[2], backup EncTable[2], and gate3[0].chan[1]. I can't see anything different between motors 2 and 3. Did #2home, then stopped it with #2jog/ after I saw HomeComplete to keep it from running into the hard stop when it tries to post-trigger-move to 0. The position shown is where I expect 0 to be. Then did #3home, and it stopped happily at 0 at the home flag as expected. No kinematics, just have #2->100000y backup.txt

The motor position shown in the position watch window jumps to that count. I can j=-5,000,000 and it will jog to that spot where it finds the home flag. After powering on today, the position that it picks up at the home flag is now -12,000,000ish instead of -5,000,000ish, at the same physical location. Nothing running at all except me typing #2home in the terminal.

Trying to get a homing search move to work for an incremental encoder. I have Motor[2].HomeOffset=0. I run #2home, it does the homing search. It's set to capture on the Home flag, which works, and the Motor[2].HomeInProgress changes to HomeComplete. However, when this happens, the motor position gets set to -5,000,000ish counts and it tries to post-trigger-move to position 0, which is outside of travel. What am I doing wrong that when it sees the home flag, the position gets set to a non-zero value? I have a 2nd identical motor configured exactly the same which works as expected - the position at the home flag gets set as the 0 point and it stops moving.

Tangential question -- Richard, why do you recommend not having the 2nd gantry motor assigned to the coordinate system? What I've seen is that doing "&1 enable" will not actually enable the 2nd motor, and with Motor[1].FaultMode=1, a fault on the first will not kill the 2nd motor, unless it is assigned with "&1#2->0"