well let me ask to beat a dead horse one more time...
can you make sure there are NO debug point breaks in the scripter, start the debugger, then F11 until it loops...
If your's still works, then there must be something in W8, 64bit (w8.1 technically)....... I am running the same M4H version as you are, and I am running the Stock OEM MachMilll profile and Screenset without any modules or anything else active... Just to make sure nothing else is running...
kinda frustrating..
Not really a show stopper, since with breakpoints, F5 and NOT exiting the funciton, but hitting the stop debug before the end (on the dummyvar), I can still debug... A mystery I guess.
Scott
Scott,
You probably know there is a 'auto' breakpoint, but other than that, there were no break points set. F11 steps thru the entire file as you can see by the snip I posted. I don't know a lot about Lua at this point, but from what I read, it can be a stickler about file locations. I have another 'C' ish Programming environment that's like that. Compiles fail because it can't find Includes and the files are right there. Alas, the compiler is looking for them in some obscure place and I have found no way to change that. It *might* be that Lua is similarly arranged, but the errors are not exactly verbose, so you don't get much of a hint as to what its unhappy about. At least with the other one, I get the full path where the thing is looking for the file. Did you follow (exactly) the sequence I posted including the file location and name?
FWIW I had two issues with 64 bit Win7 pro (be sure to mention pro if it is. they are different). Both were Modbus related as that's what I was working on at the time. Seems unlikely these would be crashing the editor, but its all I have to offer, so here it is:
Win7 was blocking the Modbus traffic. You mentioned frustrating . . MACH4 reported 'Modbus0 ok' and displayed a loop rate . . . but it was talking to a black hole . . nothing was getting in or out, and each of the data types (MACH4 calls them 'functions') was error red. I don't know what Modbus uses to check operation, but it's not closed because Modbus thinks it is talking to someone and there's nobody home. In any case, Run as Admin removed the guard dog and things started working.
It occurs to me that if you were running without being admin, the files you made *might* not have enough permissions, so you should check that also. If you follow my sequence exactly that potential would be eliminated. Long shot, but the problem is in your system and you are down to shots in the dark, so it can't hurt.
My other problem was with the network config. Once I had Modbus TCP running, in order to plug both the Processor and the main network into the machine without having to flip back and forth (reconfiguring TCP4 each time) I set up my single NIC with two hard coded IP. Even tough the Modbus IP is hard coded in the config, MACH4 Modbus *apparently* was trying to get data from the Internet side IP and not the connected processor IP (if that makes any sense).
I stuck a second NIC in the machine and configured it hard coded 2dn network to the external processor and restored the main network (rounter,internet) to auto IP, etc. Modbus stays focused on the 2nd hard coded net and all runs well, and simultaneously. I don't know what the actual problem is, but a $40 NIC card solves it, so I'm not inclined to pursue it beyond that. The MACH4 TCP Modbus will literally run for days on end while I do all of my regular work on the same computer. Impressive.
Again, it seems hard to imagine these issues would be effecting the Lua editor, but the network setup confused the Modbus comms, and as I mentioned earlier, the editors seem to be picky about file locations, so its a long shot, but maybe Lua is checking the network for libraries or something like that. Perhaps it was set to look for libraries on a network by the developers and inadvertently left that way?
That's about all I can think of. Sorry all guesses.
Meet the new Boss . . Same as the Old Boss.