Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: django013 on May 01, 2017, 03:27:33 AM
-
Hello,
with my first steps in lua I created a faked table control for the tool table. Awful how fast lua is - even in a VM!
With the '+' and '-' buttons I can scroll through the tools table.
Now I'd like to add the slider as scrollbar. The '+' and '-' buttons already use the slider value to read the tools, but there's no link to moving the slider. The slider has no 'on-update' script, so how can I create something similar?
And next question:
Tabbing through the entryfields works fine, but after the last field, the tab disappears in deep space ...
Is it possible to create a tab-group, so that the tab jumps to the first entryfield after leaving the last one?
-
You could use the PLC and compare the value of the slider to the current tool number and if the current tool is not equal to the slider value then change tool number to the value.
DazTheGas
-
Thank you for your support!
Uh - I have to confess, I don't understand the mach-way yet.
Seems like I have to think more than an embedded programmer, than a pc-programmer.
I'll try it out.
It looks like I don't understand the meaning of "single block" function/signal. I thought, the meaning was: execute a single gcode and then stop, but that does not work at all. I have a togglebutton attached to the output-signal "single block" and running a gcode script it makes no difference, whether the button is pressed or not.
From the experience with cooling and the like, I guess, the togglebutton does its job right and the signal is switched. May be the other part of the signal handler is missing?
The codepage issue is not limited to the interaction of external editor and mach. It is related to entryfields and static text too. See the pictures below.
Additionally it looks as if the field to hold the description text is too small. Is it possible to increase the size?
And then I would like to add another field to the tooltable:
usually mill cutters have at least 2 length informations - the blade length and the shaft length.
For machining only the shaft length is relevant, but on toolchange, the blade length could be relevant to the (human) tool changer :)
Having enuf size at the description field I could enter that length there, but I'd prefer an extra field for this information.
-
That output is meant to drive a LED or panel indicator. It does not activate anything. All outputs are this way. Only inputs can activate anything.
Look at a stock screen set and see how the Single Block button activates single block.
As far as the codepage goes, G code is only ASCII. The API only supports ASCII. So assume that anything other than ASCII may not work correctly. The only thing that will support NLS is the stock Windows controls (anything in the .po files).
You can add any fields you want to the tool table. View->Tool Table. Then Edit->Table Fields... Then the User Fields tab. :)
Steve
-
Hi Steve,
That output is meant to drive a LED or panel indicator. It does not activate anything. All outputs are this way. Only inputs can activate anything.
Hm, ok - so an output can switch a relais, but if I want to connect a hardware toggle-button to the screen toggle-button, than I have to use an input event?
Look at a stock screen set and see how the Single Block button activates single block.
Yes, I realized, that some buttons are bound to external signals and have a function call attached.
If I want to use the signal-line as connection between external and screen switch, shouldn't I then perform the action in the signal script?
As far as the codepage goes, G code is only ASCII. The API only supports ASCII. So assume that anything other than ASCII may not work correctly. The only thing that will support NLS is the stock Windows controls (anything in the .po files).
Hm, that's not good :(
I guess, to change code page of macro editor is quite easier, than change the screen entry field.
Are the string codepage change calls available in lua?
I guess every non-english wants to enter localized data in textfields.
//edith:
I had a quick look at wxwindows and they write, that unicode is used by default. So localized data handling should be possible ;)
Afaik the windows codepage supports german special characters too ...
You can add any fields you want to the tool table.
Great! Thank you!
-
Hm, ok - so an output can switch a relais, but if I want to connect a hardware toggle-button to the screen toggle-button, than I have to use an input event?
Yes.
Yes, I realized, that some buttons are bound to external signals and have a function call attached.
If I want to use the signal-line as connection between external and screen switch, shouldn't I then perform the action in the signal script?
Yes. With and input signal. There are lots of examples of this on this forum. Also, one can use the PMC interface. Search for examples of this as well.
You will have to read up on wxWidgets to see what all you can do with the codepage stuff. Yes, you will be using LUA, but wxWidgets is what is bound to LUA. We have other German users that have accomplished this stuff. Focus Paul is one of them. The codepage is set to an ASCII codepage in the GUI because G code does not allow anything other than ASCII. Other NLS settings such as the decimal character are purposely set as well. Meaning using a comma for a decimal character is not allowed in G code RS274NGC standard. So most things in the GUI are purposely set this way so that things like that don't accidentally end up in the interpreter. Excluding any custom LUA screen elements that you create, of course, so be careful how you integrate so that nothing non-ASCII gets into the interpreter. Filenames, profile names, etc.. are all a source of potential problems.
Steve
-
The codepage is set to an ASCII codepage in the GUI because G code does not allow anything other than ASCII.
Sorry, but that's a bad choice.
Every user is accustomed to his locale and no non-programmer knows about the problems of ascii-string versus wide-character-strings and codepage conversion, so rising the interpreter problems to the user is not a good thing.
The better choice would be, extend the interpreter to patch any non-standard characters to meet the standard. So i.e. if the interpreter finds a comma as decimal separator, it would be easy to overwrite that comma with a dot. No user has ever to be bothered with that kind of problems.
Additionally many cams write localized text in comments. A "good" interpreter takes that comment and shows it to the user - so the user reads its own language.
I think, one has to distinguish between command-level (all NC-words), which of cause is pure ASCII only, and comments and rest of application. Same is true for filesystem-handling:
No user understands, that the application vomits a "file not found" for files, he selected from file selection dialog. The user knows, that the file is there :)
I think, a today application should accept any locale from user interface and handle conversions and validations so that functionality is not affected by any wrong user input.
cheers Reinhard
-
I worked for a German company for 15 years and had to learn the meanings of the German words in the software we used. So I'm probably not going to be sympathetic at all. :) It didn't kill me. I lived! I have to admit that I did complain about it though.
I have talked with several German users about this in the early days of Mach 4's development and they all agreed that it is best to stick with the standard. It is a machine tool. It should operate the same no matter what part of the world it is in. I should be able to walk up to a CNC machine in Germany and execute G21 G01 X5.000 and expect to move 5mm and not 5000mm. The Japanese created Fanuc and all of them use a period for a decimal point.
As long as your comments are made of single byte cahracters, they will be ok. They may not display correctly do to the codepage, but it will not affect the interpreter.
Steve
-
I have talked with several German users about this in the early days of Mach 4's development and they all agreed that it is best to stick with the standard. It is a machine tool. It should operate the same no matter what part of the world it is in.
Hm, may be, you talked to the wrong guys ;)
mach is a PC-program and any user will recognize it as such. Nowadays pc-applications are localized and can handle any codepage, the user uses in his operating system.
A quite different view is the interface between mach and cnc-machine. That interface is of cause pure ASCII and should never change.
... but hey: its your decision. I only can write my opinion and that does not have to match yours :D
due to user-fields in tool table ...
How can I access those fields from lua?
In API-docs I see no function to access user fields and the type in mcToolGetData does not have entries for user-fields.
-
I disagree. I spent 20 years in the automotive manufacturing business. When we deployed machines with PCs, be them test fixtures or some type of machine control, they were no longer treated as PCs. If you used them for any other purpose than what they were put there to do, you were fired. No questions asked. Just because you can, doesn't mean you should.
When you install Mach on a PC, you have turned that PC into a machine controller. And it should be treated as such. It is no longer a PC to surf the web, do word processing, play games, email, or CAD/CAM design. We can't control what the users do in the end with their new machine controllers. But we would rather then NOT do any of that stuff.
I keep forgetting to add those tool table functions to the API documents. :(
local rc = mc.mcToolSetDataExStr(number inst, number toolnum, string fieldName, string value)
local value, rc = mc.mcToolGetDataExStr(number inst, number toolnum, string fieldName)
local rc = mc.mcToolSetDataExDbl(number inst, number toolnum, string fieldName, number value)
local value, rc = mc.mcToolGetDataExDbl(number inst, number toolnum, string fieldName)
local rc = mc.mcToolSetDataExInt(number inst, number toolnum, string fieldName, number value)
local value, rc = mc.mcToolGetDataExInt(number inst, number toolnum, string fieldName)
Steve
-
Hi Steve,
thank you for the additional calls. Works fine so far :)
When we deployed machines with PCs, be them test fixtures or some type of machine control, they were no longer treated as PCs. If you used them for any other purpose than what they were put there to do, you were fired. No questions asked.
I totally agree on that!
But I'm not a machinist, who learned programming, but a software developer who learned machinig. For so, we might have different points of view.
When I startet with software development, my tutor used to say: take care of your gui - one mouseclick wasted means hundreds of customers lost.
Related to the filename-issues he used to say: whenever I see something like that happen, I cut you off a finger.
So I had a hard start and became what I am ;)
by the way: do you use a lua-variant, that supports gettext?
If so, we could extract the user related texts to po-files. What you think about that?
... and what's in the screen-set file? Are the bitmaps part of the set-files? And the macros? Are they in the set-file or are they externally?
Or let me change the question: when I want to share my screen, what files do I have to include?
-
We use LUA 5.2. i have no idea if it uses gettext or not. :(
All of this stuff is also inside that screen set file. Images, text, control properties, etc... rename the .set to .zip and you will see it is just a zip archive. The screen is implemented in an XML file which has all of the stuff embedded in it.
Screens are meant to be user modified. You can start with one of ours from the distribution. However, you must name the screen set something different or it will get overwritten with an update! All of the stuff that uses dialogs and regular OS provided controls like menus driven by the NLS po files. But nothing in the screen set is at all unless it matched something in the po file accidently. So most likely, you will need to supply German words for the button texts and stuff (codepage issues not withstanding). None of the control property names are NLS either.
Macros CAN be external. Most of the time in the Modules directory implemented as LUA modules. The probing routines are an example of this. Be careful modifying these as an update i likely to overwrite them as well.
So to share a screen, most of the time, you would need to provide the screen set file AND any modules it may use.
Steve
-
Thanks for that info!
I'll keep on digging ;)
-
Hi,
i did a simple test to identify strings containing invalid/unsupported charaters:
local chk1 = 'Hörst Du die Glöckchen?'
local chk2 = 'einRichtigLangerText'
local x = string.find(chk1, '%W+')
local y = string.find(chk2, '%W+')
local tx = type(x)
local ty = type(y)
if (tx ~= 'nil') then print('chk1 contains invalid characters') end
if (ty ~= 'nil') then print('chk2 contains invalid characters') endThis could be used with filenames and user input from textfields.
HTH Reinhard
-
Hello,
The last line of the message in the ToolChangeMsg dialog is cut off, so I startet do search for the code.
I found it in mcMasterModule.lua - but I got messed up: wx.wxFont( ... ) is nothing I found in wx-docs. So what is this. Is it mach code, or is it lua?
I wonder, what happens with the dialog. There's plenty space down the last row, so who is responsible for the cutoff?
In ToolChangeMsg I found something like mc.mcProfileGetString(...) - is this related to gettext and po-files?
I changed the message text in the system load script, but if mcProfileGetString reads from mo-files, I revert my changes.
How can I get the sizes in the dialog right?
-
No, mc.mcProfileGetString() is a function to read the Machine.ini file settings in the machine profile. For the rest, you will just have to study up on wxWidgets and Sizers.
Steve
-
Download a copy of wxFormbuilder, apart from creating forms and dialogs etc it is great source of learning wxLua by visualy creating something and browsing through the code. All code that is created in wxFormbuilder can be used in Mach4.
DazTheGas
-
But how do we learn how to use wxformbuilder? I have not been able to get started with it and have dropped back to just trying to copy Lua code from example programs.
and making better progress. So far can't find a basic tutorial and can't seem to find a doc for wxformbuilder that is understandable. All the docs are more like a dictionary.
Isn't there something out there for the beginners to get us started? How did you guys set started with wxformbuilder? Staring at the code has not worked for me. I seem
to be doing better with Lua itself and screens.
-
@Steve
Yes, I treaten it wrong. Now I understood, that mcProfileGetString is used to determine, whether to show the toolchanger dialog.
@DTG
Thanks for the hint about wxFormbuilder. I installed the linux-variant from github - which was straight forward.
@spindoctor
starting the formbuilder shows up, that the builder is targeted to developers, that don't need it =:O
You need the wxWidgets docs. The key of wxWindows are the sizers - when you got that, the rest is straight forward.
But of cause, building gui with formbuilder is not as easy as java gui :)
anyway - I got it and I'm quite content with my new toolchanger dialog (see picture below)
My changes are - small changes to Mc Master:
--M6 message box
UI.MyFrame1 = wx.wxDialog (wx.NULL, wx.wxID_ANY, tostring(m_title), wx.wxDefaultPosition, wx.wxSize( 620, 270 ), wx.wxCAPTION + wx.wxCLOSE_BOX + wx.wxSTAY_ON_TOP + wx.wxSYSTEM_MENU+wx.wxTAB_TRAVERSAL )
UI.MyFrame1:SetSizeHints( wx.wxDefaultSize, wx.wxDefaultSize )
UI.MyFrame1 :SetBackgroundColour( wx.wxSystemSettings.GetColour( wx.wxSYS_COLOUR_3DLIGHT ))
UI.fgSizer1 = wx.wxFlexGridSizer( 2, 1, 0, 0 )
UI.fgSizer1:AddGrowableCol( 0 )
UI.fgSizer1:AddGrowableRow( 0 )
UI.fgSizer1:SetFlexibleDirection( wx.wxBOTH )
UI.fgSizer1:SetNonFlexibleGrowMode( wx.wxFLEX_GROWMODE_ALL )
UI.bSizer1 = wx.wxBoxSizer( wx.wxVERTICAL )
UI.m_staticText1 = wx.wxStaticText( UI.MyFrame1, wx.wxID_ANY, tostring(m_message), wx.wxDefaultPosition, wx.wxDefaultSize, wx.wxALIGN_CENTRE )
UI.m_staticText1:Wrap( -1 )
UI.m_staticText1:SetFont( wx.wxFont( 18, wx.wxFONTFAMILY_DEFAULT, wx.wxFONTSTYLE_NORMAL, wx.wxFONTWEIGHT_NORMAL, False, "" ) )
UI.bSizer1:Add( UI.m_staticText1, 0, wx.wxALIGN_CENTER + wx.wxEXPAND, 5 )
UI.fgSizer1:Add( UI.bSizer1, 1, wx.wxEXPAND, 5 )
UI.bSizer2 = wx.wxBoxSizer( wx.wxVERTICAL )
UI.m_okay = wx.wxButton( UI.MyFrame1, wx.wxID_ANY, "Ok", wx.wxDefaultPosition, wx.wxDefaultSize, 0 )
UI.bSizer2:Add( UI.m_okay, 0, wx.wxALL, 5 )
UI.fgSizer1:Add( UI.bSizer2, 1, wx.wxALIGN_CENTER_HORIZONTAL, 5 )
UI.MyFrame1:SetSizer( UI.fgSizer1 )
UI.MyFrame1:Layout()
UI.MyFrame1:Centre( wx.wxBOTH )
-- Connect Events
UI.m_okay:Connect( wx.wxEVT_LEFT_UP, function(event)
UI.MyFrame1:Destroy()
end ) -- end of m_okay:Connect() !
UI.MyFrame1:ShowModal(true)
return UI;
endand some changes to the screen startup code (signal array):
--M6 messagebox
[mc.OSIG_TOOL_CHANGE] = function (state)
local selectedtool = mc.mcToolGetSelected(inst)
local currenttool = mc.mcToolGetCurrent(inst)
if (selectedtool ~= currenttool) then
if( state == 1) then
local tmp = mc.mcToolGetDesc(inst, selectedtool)
mm.ToolChangeMsg('\n Ein Werkzeugwechsel wurde mit M6 angefordert. \nBitte das folgende Werkzeug einlegen:\n\n#' .. selectedtool .. '\t>>' .. tmp .. '<< ' .. '\n\n und mit Druck auf \"Start\" Verarbeitung fortsetzen!', 'Werkzeugwechsel im Gange!')
end
end
end
-
Hi,
I have a strange error:
I can't switch to tab "man. Fahrt" by property call. I already renamed the tab, but no way. Stepping through debugger raises no error, but doesn't change gui either.
I wanted to synchronize the little notebook with the main notebook in that way, that when I activate the "Einrichten" tab, the "man. Fahrt" tab should be active. When I activate "GCode ausführen" tab, then the "Maschine" tab should be active.
The strange thing is, synchronization works for GCode page, but not for "Einrichten" page.
Any idea how I could narrow the bug?
-
First of all: 3382 looks pretty good. Way smarter, than the both releases before :D
Related to my notebook-problem: I happened to note, that the first notebook-tab does the same, as the second. No other page shows this.
Could it be, that the first tabpage executes the script of the second page accidently?
-
Hello,
I tried to access the fixtures according the provided sample "Fixture Offset Table.mcs". The sample fails at GetID() where it accesses mc.FIXTURES_START
Looks like that constant is not defined. So what am I doing wrong?
-
Old example that hasn't been updated. :( Use mc.MC_FIXTURES_START and mc.SV_HEAD_SHIFT_(x) where (x) is the axis letter.
BTW, you can view these constants by viewing the LUA global table in the mcLuaEditor.
Steve
-
Hi,
more important than the constant values is the knowledge about the array content.
I'm too stupid for the mcLuaEditor - the watchwindow doesn't work for me at all. At least it does not work like the watchwindows, I know from other devtools. I can enter a variable name, but the watch window does not show the content of the variable and I can't enter a new value ...
The only way to inspect a value is the flyover-tooltip, but I didn't find a way to modify the content of a variable (during debug session).
So I don't know, how to access the global table or any other value for inspection :(
... and I don't understand the difference in api: tooltable entries are pretty easy to access. The api is straight forward.
The fixtures access looks somewhat crappy/complex to me. So as if you would say: don't touch these items, they are my proprietary ...
-
The fixture tables are setup to be Fanuc compatible. They are arranged in the system variable memory space in a specific order. Over the years, they have added more fixture offsets with G54.1 Px, where x is 1 to 99. So yes, it is complicated. If you want to understand all of this stuff, have a look at a Fanuc 21i control manual.
Most of our users are not interested in heavily modifying a screen. They usually run a stock screen set with maybe a few mods. Thus they are not getting into the nitty gritty like you are. OEMs will usually design a screen to work with a specific machine and have worked with the screen editor and LUA enough to know how to get what they want. And yes, LUA has a face only a mother could love. But it is, as you stated, stupid fast. In the end, that is why we chose it.
Mach Industrial has tool tables and fixture tables built in the screen set as controls. As well as round buttons and buttons that support transparencies. Plus Macro B conditional G code and tool life management.
Steve
-
I didn't imagine, that anybody can spent a dime in compatibility to fanuc =:O
In this part of the world, fanuc is synonym to evil :D
... and no - I don't want to read a fanuc manual.
Mach Industrial has ...
Hey, you're a good seller :D
But the fee is too much for me. If you're interested in help on a linux variant, we can talk about working together ...
Currently I can't work to get my cnc-machine ready, so I spend my time getting into mach ...
I'm nearly 60 years old and hobby should stay what it is ;)
I'm creating a new screen, cause I want to recognize the machine state from the other side of the room (5-6m) and my eyes became weak ...
I think you can imagine - that if you worked for many years for professional business only, your mind has changed toward professional. But that does not mean, that your budget has increased too ;)
-
Well... like it or not, Fanuc has the market share. You see it plain as day at IMTS. :( But I can write interpreters that will mimic anything. (I have Okuma, Haas, Siemens, and Fidia manuals) It is just that we don't have people asking for anything but Fanuc. It is what people know.
We would have to get a sale for 1000s of licenses in order for us to justify writing another interpreter though. Maybe it will happen one day.
Mach 4 will run on Linux. In fact, we ran Mach 4 on Linux when we introduced Mach 4 to the world at IMTS 2016. However, since our existing customer base was on Windows, we have concentrated on that. I'm hoping to get time to bring the Linux port up to speed soon. But it will probably be available only to OEMs at first.
Steve
-
It is just that we don't have people asking for anything but Fanuc. It is what people know.
That's completely fine.
What I don't understand: why you let fanuc customers influence your mach internals like memory organisations.
I wrote lots of interpreters too and one thing is the syntax you have to process and a very other part is the internals of your applications memory.
... anyway - its your business and I don't wonna argue on your decisions :)
Can you explain me, what's the work shift and head shift? I understand the words, but I don't know the meaning in machining. Is it a lathe issue?
I don't know such things from milling.
When/where does those values come into play?
Can you fix the sample? There are a lot of unknown items I don't know how to find out on myself.
I'm hoping to get time to bring the Linux port up to speed soon.
So do I :D
If there ever is something I can do/help on that item, please let me know.
If OEM is related to nondisclosure, I'll sign anything needed - but if OEM is about making money, I'm not your man.
cheers Reinhard
-
Well... Fanuc Macro B code depends a lot on the internal memory locations. Take probing, for example. Renishaw has Macro B probing routines for their probes. And those routines depend on those memory locations being where they think they will be. To set offsets and such. The probed locations are stored in #5061 to #5066 (X to Z user coordinates and #5071 to #5076 for the machine coordinates. Also, subroutines can be written to look and see if there is an offset in effect and then do something special like interpolating a hole with the diameter being the same no matter what the cutter diameter is, etc... It is actually quite an elegant system the more you study it. But it is complex because it is a register file system that has been patched over the years.
Work shift is a global offset that will affect all other offsets. Head shift is an offset that can be used with dual spindle machines. Neither of those is used with a convention 3 axis milling machine.
The example is fixed and will be in the next build.
Mach Linux for the OEMs first, because they will have less support issues. In the end, we will probably make a setup similar to the EMC Brain Dead Install before pushing it out to the masses and ONLY support it on the provided OS. There are just too many "flavors" of Linux out there and I don't want to have to install and test on every one of them. I'm a Linux fan. I used to write UNIX operating systems and device drivers (Motorola 68K and 88K). But Linux is an unholy mess of different distributions and everyone has their favorite.
Steve
-
The probed locations are stored in #5061 to #5066 (X to Z user coordinates and #5071 to #5076 for the machine coordinates.
Afaik linuxcnc works the same way.
It is actually quite an elegant system the more you study it.
I didn't get deep into fanuc, but from what I know, I like the macro features. Quite nice.
The example is fixed and will be in the next build.
Thank you very much!
But Linux is an unholy mess of different distributions and everyone has their favorite.
poor conclusion but very true!
I worked with many os and tried many linux flavors - I guess it was 05 when I found the most stable flavor and I did not changed since then. No problems, even on major updates and the os let me do what I want and does not force me to do things, the os wants to be done ;)
What about licenses. Will a windows-license be valid on linux systems?
May be next week I'll get my smoothstepper, so that would be the time to think about buying a license.
-
Hello,
I noted a behaviour that looked strange to me:
I changed the enabled-state of the Jog-buttons to be enabled when idle only
The button has as down-function the jog-action and as up-function stop jogging.
I could press the button in idle state, but the release-function did not fire. I couldn't stop the motion. Not with stop-button, not by opposite-button.
I had to power off the machine.
It took a while until I understood, what happened: the enable-condition is checked for press-down and release each. Does that behaviour make sense?
From my point of view, the check for the release action makes sense only when there's no press-down function attached.
But may be, I don't see all aspects ...
-
@smurph
Did you received my translations? Could you have a look at it already?
@all
The fixture-sample seems not to work (see picture below).
Additionally the values of the axis looks quite strange to me.
All axis where set to 0 when I entered the fixtures in the dialog grid. I then closed the dialog to refresh my notebook page and reopened the dialog again.
What's about the value of the A-Axis? I find no way to calculate the displayed dro-Value from the fixtures entered. Even if I take into account, that the A-Value might wrap at 360° (will it?)
The fixture-dialog seems to use a different value of mc.MC_FIXTURES_START - or why don't I get the values, when I coded the formula from your sample?
I'm very lucky - the smoothstepper arrived yesterday :)
Looking at the config dialogs of smoothstepper leads to the question: when do I need to code a plugin and what can be done with modules?
Don't know, whether I got it right: I read in faq of smoothstepper, that mach changes location of poundvars between releases.
Really? - or is it my/some misunderstanding?
-
The fixture-dialog seems to use a different value of mc.MC_FIXTURES_START - or why don't I get the values, when I coded the formula from your sample?
I solved the problem on my own ;)
There's another gap in the pound vars between G59 and G54.1 P# - so I fixed GetID from "LuaExamples/Fixture Offset Table.mcs", which I renamed to getFixtureID():
--------------------------------
--This returns the #variable that is associated with a given row of the offset table.
--------------------------------
function getFixtureID(row, axis)
local index = 0;
local exFixStart = 7001;
if (row == 0) then
index = mc.SV_WORK_SHIFT_X + axis
elseif (row == 1) then
index = mc.SV_HEAD_SHIFT_X + axis
elseif (row > 1 and row < 8) then
-- G54 .. G59
-- 5221 -- 20
index = (mc.MC_FIXTURES_START + axis + ((row - 2) * mc.MC_FIXTURES_INC))
else
-- G54.1 .. G54.100
index = (exFixStart + axis + ((row - 8) * mc.MC_FIXTURES_INC))
end
return (index);
endwith this patched function I get all fixtures of the grid :)
cheers Reinhard
-
Glad you have posted this bacause I need thus capability for my system but still stuck on the basics of file i/o and table manipulation.
Danke fiel mals again!
Keith