Correction make that Alarm D 4720...
Dave
Hi guys. I have a few more questions.
1) I tried copying some *.LIB files to MD0: to free up a bit of space in MD1:,but it only gave an error on bootup afterwords. Is this not possible or is there something I need to change to tell it to look in MD0:?
2) I have made a schedule file, This schedule file pulls in programs from the floppy drive. I have never used scheduling before now so I am not sure what to expect. I am trying to test in Machine Lock and Dry Run. When I hit Cycle Start I get Alarm D 4270 NC Start Ineffective. Any ideas whats causing the problem? I do have the Floppy Disk formatted as OSP (Seems to me this wouldn't work with a DOS Disk).
I am sure I will have more questions...
Thanks in Advance,
Dave in Ohio
Similar Threads:
Correction make that Alarm D 4720...
Dave
Pretty sure Schedule programs only work with programs stored in MD1:
If you change your schedule program to work with files on MD1: will it work?
If it does, then there is your answer.
Regards
Brian.
hi, this is what i found about that error :
maybe it is generated because you put some files in MD0 ? that error is reffering to a non-standard method for starting programs, maybe to dual buttons ? i don't know ...Code:ALARM D 4720 Dual cycle start button interlock In dual palm operations, rise of 2 pieces of button time has slipped more than the fixed time. 1->Rise time of 2 pieces of door close button has slipped more than 1[s]. 2->On the door area sensor installation specification, an operation that is inhibited with the area sensor shaded was performed with the area sensor shaded.
if p1 & p2 are in floppy folder ( perhaps device uso ), and res.lib is in md0, then your program should be ( something ) like this :
Code:{PSELECT} [fm],[pm],[fs],[n](CR) or (LF) PSELECT US0:P1.MIN,,MD0:RES.LIB PSELECT US0:P2.MIN,,MD0:RES.LIB
look, if you wanna test this, then let's make some trial programs, and begin a secvential testing :
file p1.min
V1 = 1
CALL OSUB
M02
file p2.min
V1 = 2
CALL OSUB
M02
file res.ssb
OSUB
V2 = V2 + V1
RTS
now put p1.min, p2.min and res.ssb in md1, and run this
if V2 will be 3, then move res.ssb from md1 to md0, and run this :Code:VSET V2 = 0 PSELECT P1.MIN PSELECT P2.MIN
if V2 will be 3, then move *.min files, from MD1 to US0 ( floppy, etc ), and run this :Code:VSET V2 = 0 PSELECT P1.MIN,,MD0:RES.SSB PSELECT P2.MIN,,MD0:RES.SSB
if V2 will be 3, then convert res.ssb to res.lib, register it, power-off-on, and run this :Code:VSET V2 = 0 PSELECT US0:P1.MIN,,MD0:RES.SSB PSELECT US0:P2.MIN,,MD0:RES.SSB
if v2 will be 3, then everything is ok maybe you will reach this pointCode:VSET V2 = 0 PSELECT US0:P1.MIN,,MD0:RES.LIB PSELECT US0:P2.MIN,,MD0:RES.LIB
however, i am afraid that it won't work, but i am not sure, because :
this requires the controller to register a file, for auto-loading, from a non master device, thus <> MD1I tried copying some *.LIB files to MD0
i tried this a while ago, and i did not succed : https://www.cnczone.com/forums/okuma...lways-md1.html
kindly
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...
I probably didn't describe the issue correctly. I do have the schedule file in MD1: The control doesn't seem to have any issues with it.
To be honest the real problem is the Operator(Me). I don't have mill experience and I am trying to teach it to myself during off the clock time. The other issue is I am not exactly sure what if parts have been robbed off of the machine. I was just being hopeful I could test things in machine lock/dry run if the above were the case.
Thank you for your help.
Dave in Ohio
I moved the *.LIB file back to md1: so that is no longer an issue its only like 800 bytes so not effecting memory use much. I believe that MD1: has 64k of space to play with not much but its what I got to work with. That was just an experiment to see if it would help free some memory in the future.
I am not using any SUB Programs so I'm not too worried about them at this point.
Thank you for the info on the alarm, that is different than what I was able to find.
4720NC START ineffective
This alarm will be displayed when the NC start pushbutton was pressed during prohibition of an NC startby interlocking.
This alarm will disappear when the start pushbutton is released.
This alarm will remain displayed when warming up begins during prohibition of an NC start.
[Index] None
[Character-string] None
[Codes]
None ->Door interlock
11->The program operation signal is turned OFF.
12->The NC start pushbutton was pressed or the cycle start signal was turned ON when the robot/loader retract position signal was not turned ON with system interlocking "ON."
I suppose the problem could be any of those 3 causes. More lilkey the first or third.
Very frustrating trying to learn something new when you don't even know what is broken or missing.
Thank you for help,
Dave in Ohio
hello, the lib file requires :I moved the *.LIB file back to md1: so that is no longer an issue its only like 800 bytes so not effecting memory use much. I believe that MD1: has 64k of space
... phisical storage space, thus it will consume 800bytes ( or maybe a bit more ) from the available storage space of the md1 system device
... bubble storage space, thus it will consume circa800bytes from the ( read ahead ) buffer size
one thing with the lib files, is that, after they have been loaded inside the bubble memory, you can delete them from the hdd; things will work fine, until next machine restart, when the controller will be looking for the file, so to load it again in the bubble memory
same, with min files, once you selected the program, you can delete it from the hdd; things will go well, until next time when you try to (re)select the program until then, you may execute (run) the program as many times as you wish, it will work, because it is loaded inside the bubble memory
with sdf files things are a bit different, because, even if you select it once, after that, each time you execute (run) it, it will re-load inside the bubble memory each min file
well, there are soubroutines, those ones that end with RTS they can be inside the min file, or another type ( ssb, sub, msb, etc )I am not using any SUB Programs so I'm not too worried about them at this point
soubroutines can be called by a 'call' statament, or assigning a 'free g/m' code
also, when the soubroutine is inside a lib file, that file can be registered to be loaded inside the bubble memory, each time the machine powers up
when you use a simple min file, do you still have this problem ? kindlyI suppose the problem could be any of those 3 causes. More lilkey the first or third
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...
Well, I just noticed that door interlock is missing ... Guess its time to go searching around the shop floor.
Dave in Ohio
OK friends,
I located the missing interlock and have now gotten to move onto the next error. I have attached a picture of the LCD display. Alarm B Schedule Program: Main Program Load 18000000.
I'm starting to believe I am not going to be successful at getting the scheduling to work.
Dave in Ohio
hi, try with a single program, so to minimize the testing volume; this 4 example :
a.sdf ( inside MD1 )
PSELECT FD0:A.MIN
END
a.min ( on floppy )
G50 S567
M02
maybe it works, so, after that , you develop it, and see what happens / kindly
ps : is there a code for your error ? or the only number is 18000000 ?
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...
Ok so I made a fast simple program and a simple schedule. I called them A.SDF and B.MIN, and put them on MD1:. Run it success it works. keeping A.SDF on MD1: but moving B.MIN to FD0: (Updated A.SDF to reflect change) and bam the same error as the screen shot before. Here is what the alarms/error manual has to say about alarm b 2203. The highlighted area leads me to believe that accessing the floppy drive from schedule file is simply not allowed.Trying to decipher the error number 18000000 I don't quite see how the 8 relates to bit 3 but maybe something has been lost in translation from japanese to english, who knows. If my assumptions from this lesson are wrong please correct me and show me the way. Perhaps I have just wasted my time and everyone elses time with trying to get the scheduling to work with the floppy drive. Perhaps I need to search for other options.
Thank you all for your help,
Dave in Ohio
It surely looks that way Broby. In another recent related thread some guys made it seems as though it would work, worth a shot I guess as I had some free time for experiments. I guess either figure out how to get DNC-B on the cheap, add more memory on the cheap, or the project is dead in the water. I realize for a one off I can just load the programs in one at a time but that would never work for production way too many chances to make mistakes and terribly in-efficient. Wonder if anyone out there knows the parts numbers for the DNC-B or memory hardware for u10m.
Dave in Ohio
Just to suggest something from left field....
you might try using sdf program to
COpy FD0:a.min MD0:a.min
PSelect MD0:a.min
DElete MD0:a.min
COpy FD0:b.min MD0:b.min
END
if you follow my gist.
when you push an F key, look at what is placed on the execution line.... use this as a shortcut method for jumping between screens and commands...ie CO (copy) PU (punch) PS (program select), a space is required between it and the filename.
it's years since working an Okuma...
Good idea Superman I hadn't thought of that. However I doubt it will work. Here's what the manual has to say.
Dave in Ohio
hello countryguy, try also other system devices ... maybe one or more will work
look for such folders : MD1 MD0 US0 US1 AD0 AD1 BU0 EM0 HD0 etc
i don't have experience with your machine, but i can tell, that even if there are a few system devices, each one has it's own particularities, purpose, etc ... they don't behave the same, so i don't know why the floppy does not work, or if it should work, etc / kindly
ps : codes shared by superman seems interesting; it worth a try
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...
Superman, That idea doesn't work I get Alarm B 2201 Schedule program: mnemonic code Illegal schedule program command Instructions other than PSELECT, IF, GOTO, VSET and END are designated.
Kitty, I tried the AD0: and such. They don't work either. I'm not really sure where you got those from. I have only ever seen reference to MD0, MD1, FD0, and CN0.
Dave in Ohio
hi cg, i also just tried : i could load from md1 ( main device ) ad1 ( secondary device ) hd0 (secondary device ); for your machine, maybe md0 & md1 will work ? ad0 is reserved for the conversational
i also tried to load from us0 & us1 ( usb ports ), but it did not work ... i mean the controller sees those us0 us1, it allows to copy files from them to the md1, but it is not possible to use pselect; is like the peripheral can not be pselected ? maybe is a good idea to talk with your okuma rep about pselecting from floppy ... kindly
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...
Well Kitty, I believe I am at the end of the line for schedule files. Unless someone who has done this successfully chimes in with how they were successful, it's a failed idea.
This machine is too old for USB to be an option. Also this machine doesn't have a hard drive or conversational.
There's really nothing more I can do. I guess I will finish the current project loading in the 20 separate .MIN files. It will work for this one off project, but all future hope of production runs is lost.
Dave in Ohio
A few questions:
1. Are you trying to do this on a mill? The lathe cannot do this but I believe that the mill should be able to do it depending on the control that you are attempting it on.
2. What control was the attempt made on?
3. USB should be adaptable to any machine that has a floppy drive since it is a direct bolt/plug in replacement. Older 5000 series required a floppy board, so they didn't have this ability.
4. Your sample code doesn't show an END command. Was it there but not displayed?
5. Does the program run correctly by itself outside of the schedule program?
6. Have you tried to select and run the program from the floppy without using the schedule program? If you cannot do this then the schedule program cannot do it either.
7. What method of program are you trying to do this from? Maybe method needs to be changed?
8. Have you tried to call in your Gosiger guys to see if they can help you out?
Best regards,
Experience is what you get just after you needed it.