For some reason my run on printer activation script isn't working after first job unless..

TT_Vert

My script is below. It works the first time. HOWEVER, if i do not run @gpio Kobra off (This turns printer off) after the job it will not try to run @gpio Kobra on again for the next job. I have added @gpio kobra off to the end gcode but the problem is that if a job does not finish properly, is cancelled, power outage to printer, etc. this gcode does not run so I think repetier server things the gpio pin is still powering the printer (I think sending pin high) and it's on. is there a way to ensure that the command is run w/o doing an logic test to see if the gpio pin is already sent high/low?

@func startFirstInQueue

@startNextPrintInQueue

@endfunc

@func enableAndStart

@gpio Kobra on

@echo "Powering on Kobra Max"

@timedCall startQueue 10000 startFirstInQueue

@echo "10 second delay to start print"

@endfunc

@callOnEvent "printJobAdded" enableAndStart

Thanks
Dave

Repetier

Did you deactivate and activate printer to read it? When you wrote it I assume it was already active and it does not get reread until next activation or server restart. Just in case earlier version did not contain @gpio. No reason it does not execute if there is no typo in name. Did you power of Kobra before with @gpio Kobra off? on only really runs if the state is different then last, so that would be a test. If you see it in menu as on it will not do anything as it assumes it is still on.

TT_Vert

Yes it's activated and functioning otherwise. I'm not exactly following what you are asking. Yes, my end gcode does run @gpio Kobra off after print job to shut off printer and I guess let repetier server know the state is off. However if that does not get to the end gcode for whatever reason I believe I have to manually run @gpio Kobra off before I am able to have the script run properly again to turn on printer.

This is my run after job gcode

@func PowerOffPrinter

@gpio Kobra off

@echo "Powering off Kobra Max"

@endfunc

@timedCall jobFinished 10000 PowerOffPrinter

@echo "10 second delay to turn off printer"

Perhaps I need to run this if job is aborted? But that will only run if i manually abort the job right? NOT if a power outage, etc. happens?

Is there a way to run something in my activation script that will check to see if the gpio is thought to be in one state (on) and if so to switch it off?

IF if GPIO1=1 then @gpio Kobra off

Thanks
Dave

Repetier

So you say it works if it was switched off or do you just say it does not always switch off? What I meant is just testing if that makes a difference.

You can test state

get_gpio_state(gpioName)
Returns the state of a gpio pin with given name (from Global Setting->GPIO Pins, not BCM pin number). Works for digital outputs and inputs.

So use it like
@if {{get_gpio_state("Kobra") == 1}}

to test if it is already on.

TT_Vert

IF I don't end every job w/ @GPIO Kobra off the next time I start a job my activation script will not work.

How/where can I test this context? IE how/where can i run the get_gpio_state command to see the current status? I tried that in console but no luck. Tried @get_gpio_state(Kobra) and get_gpio_state(Kobra) and a few other syntaxes.

Thanks
Dave

TT_Vert

Another thing I just noticed is when this is in this state my API calls I use on occasion to turn printer on/off w/ shortcuts on my desktop won't work either. Does that add any insight by chance? The ONLY way I can get it out of this state is to do a gpio write 0 0 and then gpio write 0 1 to turn the pin on then off. After that I can then use the @gpio commands again as designed. If I do not do this @gpio commands will NOT work

I can put it into this state at will. I have a malformed script right now called test and if i call it I get an error which is in bold below. In this state I cannot do anything w/ any GPIO pins (Even other printers that have defined GPIO pins) until I set this particular printers GPIO on/off. It's very strange but that's what has to happen.

Error when I run the malformed script below:
Mesg:18:46:30.022: error: @_endfunc at place with unmatched function start - skipping all blocks

My malformed script that I can generate the problem with
@func test

@if {{get_gpio_state("Kobra") == 1}}

@Info "test"

@endfunc

Repetier

If you want to see gpio state just run
@echo {{get_gpio_state("Kobra") }}

get_gpio_state is an expression command and can only be used in computed expressions.

Your skript is missing and @endif correct skript

@func test

@echo Kobra: {{get_gpio_state("Kobra")}}

@if {{get_gpio_state("Kobra") == 1}}

@Info "test"

@endif

@endfunc

@call test

I tested with externally changing signal and server did not see it, so for server it only counts what it did write. I will check if I can change this reading the real value instead so externally changing a pin gets reflected as well.

TT_Vert

Yeah i intentionally had a broken script to be able to duplicate the issue I run into. If the script has any error and/or doesn't complete I have to manually cycle the pin of the printer the problem script is on (On and then back off). If I do not do that the @gpio commands will not work for ANY pin. It's almost like it's in a waiting state before it'll receive anymore @GPIO commands. Probably other commands as well but I don't use any others currently.

Once it starts to run a broken script, or doesn't complete a script I can do NOTHING in console. I cannot even run @echo Hello world after calling the broken test. I get no response from console on any command typed after that.

Exec:12:09:35.330: @call test

Offl:12:09:35.331: Ignored (offline):#@endif

Mesg:12:09:35.331: error: @_endfunc at place with unmatched function start - skipping all blocks

Here is a quick video that may help to show you what occurs and how I lose all terminal access after this bad script runs. The same thing also occurs if I do NOT end a print job w/ @gpio Kobra Off (When my start gcode includes @gpio Kobra on).

Dave

TT_Vert

Also, rather than start a new thread, any idea why I would see "Only available for users with admin privledges" in Global settings | terminal? I am the only user and am an admin.

TT_Vert

I looked at the manual again and i noticed that under the gear I do not have "user profiles" listed for some reason. AFAIK I do NOT have any other repetier server account and i thought the first account was always an admin to prevent this. Here is my setup and permissions for reference. I see the option to delete user.sql is that my only option if I somehow do not have admin permissions for this account? As a test I just temp moved user.sql and created a new account and i'm good but i'm curious what adverse effects I will run into in doing this? What all do i lose?

Stop Repetier-Server Pro (see installation)

Delete the file storagedirectory/database/user.sql

Start Repetier-Server Pro

Repetier

Deleting user.sql makes you only use users but no files or config settings.

For the gpio stuff I need to run some tests when I get more time alsong with the read state change I already mentioned.

TT_Vert

I don't exactly follow what you are saying about the user.sql file but so far I've not seemed to lose anything creating a new user.sql file and I now have admin permissions on this account. I'll await your findings after testing on the gpio stuff. Just an FYI, if you look in the video I cannot do anything in terminal after that bad script runs, not just @gpio, i cannot type anything..

Repetier

Ok, I could reproduce and fix the degenerated @func with missing @endif. Problem is that the condition stack was not cleared so @if was active and falso so nothing got executed. Server assumed you are still in failed if condition.

Also gpio is now read back from pin so external commands can change pin state as well and we see it.

Install dev version for testing. (installDev on ssh console of pi)

TT_Vert

Repetier wrote
Ok, I could reproduce and fix the degenerated @func with missing @endif. Problem is that the condition stack was not cleared so @if was active and falso so nothing got executed. Server assumed you are still in failed if condition.

Also gpio is now read back from pin so external commands can change pin state as well and we see it.

Install dev version for testing. (installDev on ssh console of pi)

That actually broke all @gpio functionality. Actually I cannot even use @call Now, no matter what I cannot use @gpio $devicename on|off|toggle No error is given in console either, it just echoe the command.

Repetier

Please recheck your scripts. I have done so and the fixed script works as intended and @gpio also does change output verified with gpioreadall on ssh console and with reading back in server function durinc @call

TT_Vert

There is definitely nothing wrong w/ the @gpio commands as they worked just before i did this update.
As a basic example I show you my @gpio commands in action. Notice WPi pin 0 status on top right screen which is called Kobra. If I use the extcommand to turn on/off via GUI it works as shown. (These just call a basic sh file w/ gpio write 0 0 and or 0 1 in it). If i try to @gpio to write to pin it no longer works as you can see.

Here is a quick video to easily understand

Thanks
Dave

Repetier

I saw that gpio changed but not alway. Not sure if this is the reason in your case, but I found that with inverted polarity for output the value was read back with wrong signal so output did not do what expeted thinking it is already set. If this is the case please update to fixed dev where it now works for me with inverted polarity as well.

TT_Vert

Repetier said:

I saw that gpio changed but not alway. Not sure if this is the reason in your case, but I found that with inverted polarity for output the value was read back with wrong signal so output did not do what expeted thinking it is already set. If this is the case please update to fixed dev where it now works for me with inverted polarity as well.

That seemed to do the trick! I can now use the gpio commands again and when a script doesn't fully run for whatever reason I can still use the @gpio commands. I will report back after I test a bit more thoroughly. Thanks much, I always appreciate your support.

Dave

viratsachool

I'm not quite sure what you mean by the user.sql file, but I have admin permissions on this account now, and I haven't lost anything by making a new user.sql file. I'll wait for your results after the gpio stuff has been tested. For your information, as you can see in the video after the malicious script executes, I am unable to write anything in the terminal—not only @gpio.

Thanks